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Preface 


The  Consolidated  Afloat  Networks  and  Enterprise  Services  (CANES)  is  the  U.S.  Navy’s  next 
generation  of  networks  and  computing  infrastructure,  primarily  for  use  on  ships.  The  system 
consists  of  hardware,  operating  systems,  virtualization  software,  system  management  software, 
and  numerous  applications. 

This  report  discusses  contracting  strategies  for  the  main  hardware  component  and  inte¬ 
gration  capabilities,  referred  to  as  the  Common  Computing  Environment  (CCE),  which  will 
be  used  with  CANES.  CANES  is  not  complete  without  the  applications  and  services  it  pro¬ 
vides,  but  the  development  and  production  of  these  applications  are  not  part  of  the  CANES 
program.  We  propose  five  potential  alternatives  and  identify  a  preferred  solution.  A  series  of 
case  studies  and  interviews,  detailed  in  the  appendixes  of  this  work,  served  as  the  basis  for  our 
recommendations.  We  conducted  this  research  from  April  2010  to  October  2010. 

This  research  was  sponsored  by  the  CANES  Program  Office  in  the  U.S.  Navy’s  Program 
Executive  Office  (PEO)  Command,  Control,  Communications,  Computers,  and  Intelligence 
(C4I).  It  was  conducted  within  the  Acquisition  Technology  and  Policy  Center  of  the  National 
Defense  Research  Institute,  a  federally  funded  research  and  development  center  sponsored  by 
the  Office  of  the  Secretary  of  Defense,  the  Joint  Staff,  the  Unified  Combatant  Commands, 
the  Navy,  the  Marine  Corps,  the  defense  agencies,  and  the  defense  Intelligence  Community. 
For  more  information  on  the  Acquisition  Technology  and  Policy  Center,  see  http://www.rand. 
org/nsrd/ndri/centers/atp.html  or  contact  the  director  (contact  information  is  provided  on  the 
web  page). 
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Summary 


The  Consolidated  Afloat  Networks  and  Enterprise  Services  (CANES)  program  seeks  to  con¬ 
solidate  disparate  computing  networks.  The  program  has  a  rigorous  fielding  and  upgrade 
schedule  to  replace  the  legacy  systems  of  the  fleet.  If  successful,  the  program  will  give  the 
Navy  a  common  set  of  key  command,  control,  communications,  computers,  and  intelligence 
(C4I)  networks  across  the  fleet,  reducing  costs  and  minimizing  obsolescence  issues.  Successful 
implementation  of  CANES  will  also  represent  a  major  step  toward  creating  a  Program  Execu¬ 
tive  Office  (PEO)  organization  that  is  “horizontal,”  data-centric,  and  able  to  rely  on  a  service- 
oriented  architecture  for  success. 

While  developing  the  software  required  for  CANES,  the  Navy  let  two  contracts  for  devel¬ 
oping  the  Common  Computing  Environment  (CCE)  to  be  used  with  CANES.  Under  these 
contracts,  contractors  will  design  CANES,  identifying  specific  hardware  and  developing  the 
integration  software  necessary  to  consolidate  existing  C4I  functions.  At  the  time  this  research 
was  conducted,  the  Navy  expected  that  a  down-select  would  occur  in  late  spring  2011.  After 
this  point,  a  single  contractor  would  become  responsible  for  producing  the  CANES  design, 
refining  integration  software,  and  assembling  and  testing  the  system  in  2012  in  the  limited 
deployment  (LD)  phrase.  The  program  office  anticipated  that  a  full  deployment  (FD)  contract 
would  be  awarded  in  spring  2012.  The  successful  contractor  would  be  responsible  for  execut¬ 
ing  the  purchased  design  and  assembling  the  systems,  ensuring  that  the  integration  software 
is  functioning.  An  important  assumption  being  made  by  the  program  office  is  that  the  designs 
produced  during  system  development  will  be  build-to-print  designs  based  on  the  system  con¬ 
figuration  developed  during  system  design  and  development  (SDD)  and  tested  and  refined 
during  LD.1  The  expectation  is  that  the  CANES  program  will  then  be  able  to  leverage  a  much 
broader  production  base  for  contracting  during  the  FD  phase  of  the  program.  The  Navy  must 
also  determine  acquisition  and  supporting  contracting  strategies  for  the  FD  phase.  The  objec¬ 
tive  of  this  research  is  to  identify  which  contracting  option  for  the  FD  phase  of  the  CANES 
program  will  best  support  the  Navy’s  program  priorities  and  objectives. 

This  report  identifies  and  assesses  five  potential  contract  strategies  for  the  FD  phase  of  the 
CANES  program.  We  focus  primarily  on  initial  fielding,  which  is  expected  to  take  approxi¬ 
mately  six  years.  (Our  examination  of  other  programs  reveals  that  the  acquisition  and  contract¬ 
ing  strategy  can  evolve  to  fit  the  needs  of  the  program  as  it  matures.)  The  potential  strategies  we 
identified  are  based  on  our  understanding  of  the  program  goals  and  risks  that  we  derived  from 


1  The  term  build-to-print  refers  to  materials  received  by  the  government  from  the  contractor  that  include  the  design  of  the 
system,  identification  of  hardware  components,  information  on  how  to  assemble  the  hardware,  data  rights  to  the  software 
code,  and  instructions  on  how  to  load  and  run  required  integration  software. 
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interviews  with  program  staff  and  from  our  review  of  all  of  the  available  program  documenta¬ 
tion.  The  strategies  were  also  informed  by  lessons  learned  from  similar  programs  we  studied. 


Potential  Strategies 

We  developed  five  procurement  approaches  for  the  CANES  program.  Our  governing  princi¬ 
ples  for  developing  the  approaches  were  that  they  had  to  (1)  be  flexible  enough  to  accommodate 
the  known  and  unknown  risks,  (2)  provide  a  broad  range  of  strategies,  and  (3)  provide  best 
value  in  terms  of  price  and  quality. 

The  first  option  we  developed  would  maximize  work  to  be  done  by  a  single  prime  contrac¬ 
tor.  We  also  considered  the  opposite  option,  maximizing  work  to  be  done  by  the  government. 
The  other  three  options  allocate  specific  functions  to  varying  contractors  under  multiple  award 
contracts  (MACs)  using  an  indefinite  delivery,  indefinite  quantity  (IDIQ)  format  for  produc¬ 
tion  and  installation.  Table  S.l  shows  the  five  options  and  the  primary  functions  that  need  to 
be  performed  during  the  FD  phase  of  the  program. 

Single  Prime  Contractor 

Our  first  option,  maximizing  work  for  a  single  prime  contractor,  is  the  most  commonly  used 
acquisition  model  in  the  Department  of  Defense  for  large  acquisition  programs.  In  this  model, 
the  Navy  employs  a  single  contractor  (in  Table  S.l,  the  “prime”)  to  be  responsible  for  program 
performance.  This  minimizes  the  need  for  multiple  contractor  coordination  and  the  need  for 


Table  S.l 

Procurement  Options  for  the  Full  Deployment  Phase 


Option 

Function 

Single  Prime 
Contractor 

Multiple  Contract 
Model  A 

Multiple  Contract 
Model  B 

Multiple  Contract 
Model  C 

Government 

Design  and 
integration 

Technical  advice 

Systems 

engineering 

Configuration 

management 

In-service 

support 

Prime 

Contractor  A 

Contractor  A 

Contractor  A 

Government 

Production 

Prime 

Winners  of 
production 

MAC  IDIQ  (not 
Contractor  A) 

Winners  of 
production 

MAC  IDIQ  (not 
Contractor  A) 

Winners  of 
production 

MAC  IDIQ  (not 
Contractor  A) 

Government 
plus  winners  of 
existing  service 
center  MACs 

Installation 

Prime 

IMO 

Winners  of 
installation 

MAC  IDIQ  (not 
Contractor  A 
or  the  winners  of 
the  production 
MAC  IDIQ) 

Winners  of 
production 

MAC  IDIQ  (not 
Contractor  A) 

IMO 

NOTES:  IDIQ  =  indefinite  delivery,  indefinite  quantity.  IMO  =  Installation  Management  Office.  MAC  =  multiple- 
award  contract. 
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government-furnished  equipment  (GFE)  as  well  as  technical  risks  by  using  consistent  stan¬ 
dards  and  communication  protocols. 

There  are,  however,  disadvantages  to  this  approach.  Once  the  contract  is  awarded,  the 
government  can  do  little  to  address  subsequent  cost  and  performance  problems.2  This  model 
also  requires  new  processes  and  agreements  with  installation  activities.  Much  of  the  dollar 
value  of  such  contracts  is  negotiated  on  a  sole-source  basis  with  the  prime  contractor  after  con¬ 
tract  award,  when  the  government  has  minimum  leverage  to  obtain  best  value.  Finally,  this 
model  requires  extensive  Navy  effort  to  negotiate  many  task  orders,  delivery  orders,  and  con¬ 
tract  changes  in  a  sole-source  environment. 

Multiple  Contract  Model  A 

Model  A  uses  one  contractor  (in  Table  S.l,  “Contractor  A”)  to  conduct  the  necessary  technical 
and  engineering  effort,  including  design  and  integration.  The  contract  can  be  competitively 
awarded  but  needs  to  cover  a  number  of  fiscal  years  to  ensure  continuity  and  avoid  disruptive 
and  costly  contractor  turnover.  Assuming  acceptable  contractor  performance,  it  is  a  good  idea 
to  maintain  this  contractor  for  the  duration  of  the  program.  Production  is  carried  out  by  other 
contractors  that  receive  periodic  awards  of  delivery  orders  under  MACs  using  an  IDIQ  format. 
The  installation  is  handled  by  Space  and  Naval  Warfare  Systems  Command’s  (SPAWAR’s) 
existing  Installation  Management  Office  (IMO)  process.  This  option  allows  Contractor  A  to 
perform  all  engineering  functions  and  to  maintain  continuous  experience  for  a  long  period, 
thereby  minimizing  cost  and  risk.  Contractor  A  would,  of  course,  be  able  to  subcontract  vari¬ 
ous  functions.  This  model  also  allows  periodic  competition  for  production  of  ship  sets,  thereby 
securing  the  best  and  most  current  hardware  pricing  and  eliminating  the  risks  associated  with 
using  new  organizations,  processes,  and  contractors  for  installation.  This  alternative  also, 
however,  requires  multicontractor  coordination  and  the  provision  of  GFE  and  government- 
furnished  information  (GFI).  This  may  make  it  more  difficult  to  negotiate  contract  changes 
and  to  hold  contractors  responsible  for  their  performance. 

Multiple  Contract  Model  B 

This  approach  has  many  of  the  same  characteristics  and  advantages  as  Model  A.  It  adds  peri¬ 
odic  competitions  for  installation,  which  has  the  advantage  of  keeping  the  pressure  on  instal¬ 
lation  contractors  to  improve  cost.  This  approach  has  the  same  disadvantages  as  Model  A 
and  additional  disadvantages  in  its  requirements  for  (1)  extra  government  effort  to  set  up  and 
administer  two  sets  of  MAC  contracts  and  (2)  new  processes  and  agreements  for  coordinating 
the  installations.  This  model  may  also  require  modifications  to  Navy  and  SPAWAR  policy.3 

Multiple  Contract  Model  C 

Model  C  uses  one  set  of  MAC  IDIQ  contracts  to  combine  CANES  production  and  installa¬ 
tion.  This  approach  has  all  of  the  advantages  of  Model  B,  as  well  as  the  advantage  of  holding 
one  contractor  responsible  for  each  ship.  It  also  has  all  of  the  disadvantages  of  Model  B  plus  a 


2  Changing  the  prime  contractor  once  it  has  been  selected  is  expensive.  Furthermore,  penalizing  the  prime  contractor  for 
poor  performance  is  an  ineffective  means  to  improve  performance. 

3  See  SPAWAR,  2006.  Current  policy  states  that  all  installations  must  be  managed  through  the  Installation  Management 
Office. 
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greater  likelihood  that  the  IDIQ  awards  will  exceed  $10  million,  thereby  permitting  MAC  bid 
protests  under  the  Federal  Acquisition  Regulation  (FAR). 

Government  Option 

Under  this  approach,  the  technical  and  engineering  functions  are  assigned  to  SPAWAR’s  Sys¬ 
tems  Centers  (SSCs).  The  government  would  procure  information  technology  hardware  using 
existing  MACs  and  assemble  and  wire  them  into  racks  at  the  SSCs.  The  IMO  would  handle 
the  installation  using  the  existing  ship  installation  process.  This  option  has  the  advantage  of 
minimizing  contract  actions,  using  existing  installation  processes,  and  giving  the  program 
office  excellent  oversight  of  performance.  There  are  disadvantages,  however.  This  is  an  uncon¬ 
ventional  acquisition  model  for  such  a  large  program.  There  is  a  perception  that,  because  the 
program  office  has  so  few  tools  to  ensure  good  performance,  the  government  would  not  be  the 
most  effective  performer.  Only  a  very  small  amount  of  the  program’s  dollar  value  would  be 
awarded  through  competitive  contract,  and  the  program  office  would  have  little  leverage  over 
the  workload  priorities  of  other  government  organizations. 


The  Preferred  Approach:  Multiple  Contract  Model  A 

In  any  of  the  above  five  strategies,  the  government  could  choose  to  let  a  contract  to  an  entirely 
new  contractor  in  the  FD  phase  of  the  program  for  any  of  the  design/redesign,  production/ 
manufacture,  and  installation  activities.  There  is  inherent  risk  in  shifting  from  one  contrac¬ 
tor  to  another  when  moving  from  the  development  to  the  production  phase  of  the  program. 
The  Navy  is  planning  to  mitigate  such  risk  by  acquiring  the  data  and  information  that  a  new 
contractor  will  need  to  produce  the  system.  The  Navy  intends  to  own  the  design  of  the  system 
and  all  technical  instructions  and  manuals  related  to  production  and  installation  of  the  system. 

A  review  of  programs  whose  characteristics  are  similar  to  those  of  CANES  reveals  that  a 
number  of  contracting  strategies  can  yield  a  successful  product.  There  is  no  single  “right”  con¬ 
struct.  Some  programs  we  examined  adopted  a  single  prime  contractor  model;  others  assigned 
different  program  tasks  to  various  contractor  and  government  entities.  Although  any  one  of 
the  alternatives  can  be  made  to  work,  there  were  some  common  themes  among  successful 
programs. 

First,  the  government  played  a  leading  role  in  the  successful  programs.  Government  rep¬ 
resentatives  participated  in  specific  technical  and  managerial  activities;  importantly,  the  gov¬ 
ernment  retained  management  and  decisionmaking  responsibilities  for  the  program.  Second, 
although  contractors  identified  what  was  technically  possible  and  carried  out  the  lion’s  share 
of  the  actual  software  and  hardware  development,  the  government  maintained  responsibility 
for  specifying  the  requirements  and,  critically,  for  testing.  The  government  also  maintained 
responsibility  for  the  development  of  the  architecture  specification.  Third,  the  government 
guided  the  integration  effort  by  clearly  specifying  the  roles  and  responsibilities  of  the  various 
parties  through  an  integration  plan  and  integration  strategy.  This  guidance  included  govern¬ 
ment  participation  in  and  management  of  standards  and  protocols  required  to  aid  the  integra¬ 
tion  effort.  Although  standards  were  proposed  by  contractors  in  some  cases,  the  government 
approved  or  disapproved  those  recommendations.  This  required  maintaining  technical  exper¬ 
tise  within  the  government  program  offices,  even  though  most  of  the  actual  programming 
work  was  done  by  contractors.  Fourth,  successful  programs  assigned  functions  to  the  organiza- 
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tions  that  could  provide  the  best  value  (quality  and  cost).  Successful  programs  provided  incen¬ 
tives  for  schedule  performance  but  also  permitted  the  flexibility  required  to  carry  out  constant 
technical  updates  and  to  cope  with  uncertainties,  such  as  integration  challenges  and  changing 
operational  schedules. 

Multiple  Contract  Model  A  assigns  the  technical,  production,  and  installation  functions 
to  the  organizations  that  can  provide  the  best  value.  It  keeps  competitive  pressure  on  costs  of 
ship-set  production  and  minimizes  the  risk  of  installation  failure  by  using  the  existing  IMO 
process  for  installation.4  Model  A  is  superior  to  the  single  prime  contractor  option  in  several 
important  respects: 

•  It  requires  active  and  continuous  government  involvement,  which,  as  noted  earlier,  is  a 
common  theme  among  the  successful  military  information  technology  (IT)  programs  we 
reviewed. 

•  It  obtains  frequent  competitive  prices  for  IT  hardware  in  an  environment  where  hardware 
capabilities  and  prices  are  constantly  improving. 

•  It  uses  proven  SPAWAR  IMO  processes  to  install  CANES  on  board  warships  and  does 
not  require  the  development  of  new  processes  and  the  negotiation  of  numerous  contract 
changes  to  reflect  constantly  changing  ship  schedules  and  shipyard  service  costs. 

Because  it  uses  the  IMO  for  CANES  installation,  Model  A  is  superior  to  Models  B 
and  C,  which,  like  the  single  prime  contractor  option,  require  the  development  of  new  pro¬ 
cesses  and  the  negotiation  of  numerous  contract  changes.  Model  A  is  also  preferable  to  the 
government  option  because  it  obtains  competitive  prices  for  IT  hardware. 


Considerations  for  Any  Contracting  Strategy 

All  the  risks  and  lessons  learned  point  to  the  need  for  a  flexible  and  agile  contracting  strategy. 
The  amount  of  risk  in  the  FD  phase  will  depend  on  the  quality  of  the  design  that  emerges 
from  the  design  phase  of  the  program.  PEO  C4I  should  consider  a  strategy  that  will  help 
mitigate  the  risk  of  receiving  an  incomplete  or  inadequate  design.  In  addition,  there  should  be 
flexibility  to  meet  changing  system  requirements  through  periodic  upgrades  and  to  eliminate 
unwanted  or  infeasible  requirements.  We  recommend  that  the  PEO  adopt  a  “crawl,  walk,  run” 
approach  that  targets  the  most  important  requirements  first  and  then  develops  the  capability 
over  time.  In  a  program  as  technically  complex  as  CANES,  evolving  a  capability  is  less  risky 
than  attempting  to  develop  all  the  desired  capabilities  in  a  single  step. 

In  addition,  the  program  office  should  be  aware  of  both  some  common  network  integra¬ 
tion  pitfalls  and  some  potential  mitigation  strategies.5  For  example,  two  common  problems 
have  been  (1)  a  lack  of  sharing  of  proprietary  source  code  between  the  government  and  indus¬ 
try  and  (2)  a  lack  of  technical  manuals.  The  FD  contract  should  ensure  that  such  items  are 


4  Interviews  with  CANES  program  office  staff  provided  examples  of  cases  where  the  IMO  was  not  used.  In  one  case,  the 
installation  was  significantly  delayed  and  ultimately  scheduled  through  the  IMO  because  the  selected  contractors  did  not 
have  the  necessary  qualifications  and  certifications  to  enter  the  shipyard. 

5  Programs  are  discussed  in  Chapter  Four. 
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addressed.  Mitigation  strategies  for  the  common  network  implementation  pitfalls  observed  in 
our  case  studies  include 

•  creating  an  integrated  requirements  document  (for  all  ship  networks)  that  contains  indi¬ 
vidual  functional-area  requirements 

•  requiring  the  design  team  to  work  with  the  operational  users  of  the  system  to  identify 
system  functional  and  end-user  requirements  before  system  concept  design 

•  writing  a  well-defined  concept  of  operations  that  encompasses  the  entire  system  and  user 
functional  interactions  of  individual  networks,  ship  systems,  and  other  interfaces 

•  reducing  the  amount  of  manually  inputted  data  by  allowing  data  to  be  passed  from  system 
to  system  whenever  possible 

•  conducting  a  risk  analysis  and  implementing  a  management  process  with  full-scale  test¬ 
ing  for  each  ship  or  ship  type  under  dynamic  shipboard  conditions  for  all  new  technol- 
ogy,  equipment,  and  architectures  or  configurations  that  have  never  before  been  used  on 
a  ship 

•  conducting  a  land-based  test  of  the  system  prior  to  shipboard  installation,  or,  if  that  is  too 
costly,  developing  a  virtual  integration  concept  that  involves  all  system  sites 

•  ensuring  that  contractor-furnished  equipment  (CFE)  is  not  designed  and  procured  years 
before  installation  so  as  to  avoid  hardware  obsolescence 

•  developing  a  life-cycle  software  and  maintenance-control  plan 

•  establishing  a  dedicated  organizational  entity  to  serve  as  life-cycle  manager  in  an  in-house 
Navy  organization  with  staffing  components  from  headquarters,  naval  organizations,  and 
private  companies 

•  establishing  a  distinct  program  and  system  integration  office  that  is  responsible  for  inter¬ 
face  control,  management  of  all  CFE  and  GFE  system  hardware,  software  maintenance 
and  control,  systems  integration,  system-level  functional  requirements,  control  for  ser¬ 
vices  and  resources,  budget  formulation,  future  technical  changes,  interface  control,  and 
plan  execution 

•  conducting  several  meetings  one  year  before  the  first  system  delivery  to  determine  whether 
requirements  are  feasible  or  need  to  be  modified 

•  putting  C4I  personnel  and  systems  on  board  earlier  in  the  shipbuilding  process  so  that 
the  users  are  properly  acclimated  to  the  network 

•  providing  more  shipboard  training  or  establishing  a  reliable  remote  management  capabil¬ 
ity  to  effectively  monitor  the  health  of  the  network 

•  ensuring  that  networks  are  not  “ship-unique,”  thereby  allowing  for  cost-effectiveness  in 
schoolhouse  training 

•  synchronizing  multiple  upgrades  when  upgrading  systems  so  as  to  identify  adverse  effects 
earlier. 
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Introduction 


The  Navy  faces  the  challenge  of  having  a  large  number  of  networks  on  board  ships  that  are 
often  not  well  integrated  with  other  systems  and  are  increasingly  costly  and  difficult  to  main¬ 
tain  and  operate.  Some  Navy  ships  have  as  many  as  50  separate  networks — and  as  many  sets  of 
training  and  support  issues.  Meanwhile,  commercial-sector  information  technology  has  been 
moving  toward  service-oriented  architectures  that  are  cheaper  and  easier  to  change  and  that 
provide  much  greater  long-term  flexibility  for  users. 

To  address  these  operability  issues  and  to  adopt  the  best  evolving  commercial  practices, 
the  Navy  has  developed  the  Consolidated  Afloat  Networks  and  Enterprise  Services  (CANES). 
CANES  represents  the  Navy’s  approach  to  the  next  generation  of  networks  and  computing 
infrastructure,  primarily  for  shipboard  use. 

CANES  components  include  hardware  and  software  for  an  operating  system,  systems 
management,  virtualization,  and  numerous  applications.  The  combination  of  hardware  and 
virtualization  software,  which  will  allow  for  integration  of  disparate  systems,  is  referred  to  as 
the  Common  Computing  Environment  (CCE).  The  program  (minus  the  cost  of  applications) 
is  estimated  to  cost  more  than  $1.5  billion  (Department  of  the  Navy,  2010)  to  outfit  a  large 
portion  of  the  fleet  and  Maritime  Operations  Centers  ashore. 

Not  only  is  the  program  sizeable,  it  also  has  an  ambitious  schedule.  The  Navy  intends 
for  CANES  to  reach  initial  operational  capability  (IOC)  in  fiscal  year  (FY)  2012.  The  Navy 
is  developing  a  set  of  core  services  (software),  but  may  desire  to  contract  this  function  in  the 
future.  The  Navy  has  let  two  contracts  for  developing  the  CCE.  At  the  time  this  research  was 
conducted,  the  Navy  was  scheduled  to  conduct  a  down-select  in  spring  201 11  for  the  limited 
deployment  (LD)  phase  of  the  program,  with  a  full  deployment  (FD)  contract  being  let  in  2012 
(Figure  1.1). 

The  Navy  must  determine  acquisition  and  supporting  contracting  strategies  for  the  FD 
ph  ase  of  the  CANES  program.  The  objective  of  this  research  is  to  identify  and  assess  which 
contracting  options  for  full  deployment  of  the  CANES  program  will  best  support  the  Navy’s 
program  priorities  and  objectives.  This  determination  requires  answering  questions  such  as  the 
following 

•  What  are  the  technical  and  program  objectives  of  the  CANES  program? 

•  What  work  needs  to  be  accomplished  for  full  deployment? 

•  What  are  the  potential  issues  and  challenges  to  the  program? 

•  What  should  the  program  office’s  role  be  in  key  tasks? 


1  As  of  December  12,  2011,  a  down-select  had  not  taken  place. 
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Figure  1.1 
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•  What  program  elements  should  be  acquired  through  competitive  contracts  and  what  are 
the  most  appropriate  contracting  strategies  and  incentives? 


Research  Approach 

To  determine  the  best  contracting  strategies  for  CANES  full  deployment,  we  completed  five 
tasks  (Figure  1.2).  First,  we  clarified  program  needs  and  objectives  as  pertaining  to  this  research. 
Second,  we  identified  key  tasks  for  full  deployment,  including  technical  and  programmatic 
challenges.  Third,  we  developed  contracting  strategies.  Fourth,  we  assessed  these  contracting 


Figure  1.2 

Tasks  Completed  to  Determine  Contracting  Strategies 
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strategies  in  light  of  experiences  of  other  programs  and  other  relevant  considerations.  Fifth,  we 
identified  a  preferred  strategy. 

To  accomplish  these  tasks,  we  interviewed  several  people  within  the  program  office, 
including  all  Integrated  Project  Team  (IPT)  leaders  as  well  as  the  Tactical  Networks  Program 
Manager  and  deputy  program  manager.  At  the  direction  of  the  Navy,  and  so  as  not  to  inad¬ 
vertently  reveal  any  preferential  information,  we  did  not  interview  any  potential  contractors. 
We  reviewed  all  available  CANES  program  documents,  such  as  the  Architectural  Specifica¬ 
tion,  the  Functional  Specification,  the  System  Engineering  Plan  (SEP),  Testing  and  Evalua¬ 
tion  Master  Plan  (TEMP),  the  Acquisition  Strategy,  and  Application  Integration  concept  of 
operations  (CONOPS)  documents.  We  conducted  case  studies  of  other  programs  (detailed  in 
Appendixes  A  through  G),  including  programs  both  in  the  Navy  and  in  other  Services,  review¬ 
ing  available  program  documentation  and  interviewing  staff. 


Research  Assumptions 

The  Department  of  Defense  (DoD)  is  currently  pursuing  many  efficiency  initiatives  (Under 
Secretary  of  Defense,  2010).  The  Under  Secretary  of  Defense  for  Acquisition,  Technology  and 
Logistics  (AT&L)  has  called  for  greater  use  of  firm-fixed-price  (FFP)  contracting,  more  compe¬ 
tition,  and  adjustments  to  progress  payments.  Accordingly,  we  assume  that  the  Navy  will  wish 
to  pursue  FFP  contracting  and  competition  within  the  CANES  program. 

Other  assumptions  guiding  our  exploration  of  contracting  strategies  include  the  following: 

•  For  the  CANES  program,  schedule  and  cost  are  the  primary  considerations. 

•  Desired  capability  will  be  gained  through  multiple  increments,  allowing  schedule 
adherence. 

•  Contract  strategy  should  maximize  competition. 

•  The  government  will  be  in  a  position  to  have  an  open  competition  for  the  CCE  in  FD. 
This  means  it  will  have  obtained  all  data  rights,  designs,  and  knowledge  required  for 
future  winners  of  competitive  contracts  to  develop  system  increments. 


Organization  of  the  Report 

Chapter  Two  of  this  report  provides  an  overview  of  the  CANES  program  and  describes  key 
program  tasks.  Chapter  Three  provides  an  overview  of  five  potential  contracting  strategies  and 
summarizes  the  benefits  and  drawbacks  of  each.  Chapter  Four  presents  additional  “lessons 
learned”  from  programs  analogous  to  CANES.  Chapter  Five  reviews  other  lessons  that  we 
consider  useful  to  the  program  office,  independent  of  the  contract  strategy  chosen.  Chapter  Six 
describes  the  preferred  alternative  and  summarizes  our  conclusions. 


CHAPTER  TWO 


The  CANES  Program 


The  goal  of  the  CANES  program  is  to  better  consolidate  and  control  key  command,  control, 
communications,  computers,  and  intelligence  (C4I)  networks.  Historically,  it  has  been  diffi¬ 
cult  to  integrate  these  “bolt-on,  stove-piped”  designs  because  very  few  were  designed  to  be  inte¬ 
grated.1  CANES  is  a  major  step  toward  a  Program  Executive  Office  (PEO)  C4I  organization 
that  is  “horizontal,”  data-centric,  and  able  to  rely  on  a  service-oriented  architecture.  The  goal 
of  the  program  is  to  field  a  single,  consolidated  enterprise  information  environment  on  board 
ships  and  shore-command  nodes. 

When  implemented,  CANES  will  provide  a  common  computing  and  storage  infrastruc¬ 
ture  and  core  services  for  hosted  applications.  It  will  provide  platform-network  connectivity  for 
all  levels  of  security.  CANES  will  also  attempt  to  incrementally  collapse  Unclassified,  Secret, 
Secret  Releasable,  and  Sensitive  Compartmented  Information  (SCI)  enclaves  while  preserv¬ 
ing  the  confidentiality  of  all  data  within  all  security  classifications.  The  primary  functions  of 
CANES  are  to  provide  intraship  communications,  ship-to-ship  and  ship-to-shore  communica¬ 
tions,  and  an  infrastructure  to  support  communications  for  tactical  and  administrative  appli¬ 
cations  that  rely  on  an  information  technology  (IT)  local  area  network  (LAN).  IT  LAN-based 
communications  are  primarily  for  data  but  also  include  video  and  voice. 


CANES  Is  More  than  Just  the  CCE  Hardware 

In  addition  to  hardware,  PEO  C4I  is  buying  a  software-intensive  system  capable  of  integrating 
numerous  other  applications  and  services.  Such  software  must  have  nine  key  system  attributes, 
or  KSAs  (Table  2.1). 

Many  of  the  key  attributes  of  CANES  may  “ride  on,”  or  utilize,  the  CCE  (listed  in  KSA 
5).  Their  requirements  and  goals,  however,  extend  beyond  the  hardware  in  the  commercial- 
off-the-shelf  (COTS)-based  CCE.  The  CANES  program  manager’s  initial  focus  on  the  CCE 
likely  stems  from  the  plans  to  integrate  many  of  the  KSAs  on  the  CCE,  which  in  turn  could 
lead  to  substantial  cost  savings.  This  is  true  for  Core  Infrastructure  Services,  much  of  Informa¬ 
tion  Management,  and  parts  of  Network  Support,  Voice,  Video,  and  Network  Access.  Some  of 
these  KSAs,  such  as  Voice,  Video,  and  Systems  Management,  will  also  have  designed  capability 
that  exists  outside  the  CCE. 


1  The  PEO  C4I Master  Plan  discusses  this  in  more  detail.  The  document  discusses  a  vision  of  “shaping  and  aligning  pro¬ 
grams  to  achieve  a  cost-effective,  fully  integrated  PEO  C4I”  (Navy  Program  Executive  Office,  2009). 
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Table  2.1 

Key  System  Attributes  (KSAs)  in  the  CANES  Specification 


Key  System  Attribute 

Comment 

1:  Network  Access 

Information  transport  both  wired  and  wireless 

2:  Voice 

Through  voice  over  internet  protocol  (VoIP)  (not 
replacing  existing  voice  communications) 

3:  Video 

Video  teleconferencing  (VTC)  capability 

4:  Network  Support 

Information  assurance,  authentication,  and  certification 

5:  Information  Management 

Application  hosting  (CCE) 

User  data  storage 

Printed  media 

Peripheral  devices  (Blackberries) 

Email  and  calendar  applications 

Office  productivity 

Messaging  tools 

Collaboration  (data/audio  conference) 

Knowledge  management 

6:  Core  Infrastructure  Services 

Data  mediation 

Discovery 

Portal  access 

User  profiling  and  customization 

Machine-to-machine  messaging 

Service  orchestration 

7:  Systems  Management 

Performance,  availability,  and  service-level  management 
Fault,  problem,  incident,  and  service  desk  management 
Configuration,  change,  and  release  management 

Security  management  (security  policy  violations) 

Capacity  management 

8:  Materiel  Reliability 

Mean  time  between  failure 

9:  Ownership  Costs 

Operating  and  support  costs  considered  in 
decisionmaking 

SOURCE:  CANES  Program  Office,  2009a. 


Much  of  the  technical  risk  for  CANES  is  in  the  software.  Figure  2.1,  taken  from  the  PEO 
C4I  Master  Plan ,  highlights  that  “CANES  Full  Hosting”  will  include  a  very  robust  network 
hardware  infrastructure  layer  with  software  and  infrastructure  services  evolving  in  the  iterative 
growth  of  CANES.  The  Network  Hardware  Infrastructure  Layer  will  host  subsequent  incre¬ 
ments  of  software  to  realize  the  desired  CANES  capability. 


CANES  Elements 

CANES  is  based  on  the  consolidation  of  C4I  surveillance  and  reconnaissance  (C4ISR)  net¬ 
works  for  afloat  platforms  and  Maritime  Operations  Centers  ashore.  It  will  consolidate  several 
existing  networks  into  a  single  system  meeting  the  requirements  of  many  legacy  systems.  These 
include  Integrated  Shipboard  Networks  Systems  (ISNS),  SCI  networks,  Submarine  Local  Area 
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Figure  2.1 

Application  Hosting  Model 
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SOURCE:  Navy  Program  Executive  Office,  PEO  C4I  Master  Plan,  2009. 

NOTES:  EA  candidates  start  at  lower  left — disparate  hardware.  Any  application  or  system  can  consume  core 
services  or  BNIDS  at  right.  Ping,  power,  and  pipe  refer  to  provision  of  network,  processing  time,  and  network 
connections. 
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Network  (SubLAN),  Combined  Enterprise  Regional  Information  Exchange  System-Maritime 
(CENTRIX-M),  Video  Information  Exchange  System  (VIXS),  Global  Command  and  Con¬ 
trol  System-Maritime  (GCCS-M),  Distributed  Common  Ground  System-Navy  (DCGS-N), 
and  Shipboard  Video  Distribution  System  (SVDS).2  In  addition,  the  office  responsible  for 
CANES  will  assume  hardware-procurement  activities  currently  carried  out  by  offices  respon¬ 
sible  for  application  programs  soon  to  be  hosted  within  CANES.  In  its  initial  deployment 
configuration,  CANES  will  not  support  applications  for  weapon  systems,  ship-engineering 
functions,  or  navigation. 

CANES  is  a  software-intensive  system.  Its  many  levels  of  software  include  operating  soft¬ 
ware,  system  management,  virtualization,3  and  applications  or  services  such  as  email.  Initially, 
the  CANES  program  had  two  main  developmental  activities:  (1)  the  CCE,  which  covered 
hardware  and  all  the  software,  except  that  for  applications  and  services,  and  (2)  software  to 
support  core  services,  referred  to  as  Afloat  Core  Services.  The  government,  however,  deter¬ 
mined  it  would  be  less  risky  to  provide  a  set  of  core  services  to  the  developers  as  government- 
furnished  equipment  (GFE),  meaning  that  only  the  CCE  will  be  developed  at  this  time.  The 
government  could  later  contract  for  future  CANES  services  and  applications. 


1  We  describe  these  systems  in  Appendix  H. 

3  Virtualization  software  allows  multiple  disparate  applications  to  run  on  a  single  server. 
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The  Common  Computing  Environment 

The  Navy  has  let  two  contracts  for  developing  the  CCE.  The  CCE  is  expected  to  be  a  COTS 
systems  integration  effort.  The  Navy  seeks  a  system  developer  that  will  use  state-of-the- 
industry  networking  hardware  in  its  design.  The  government  will  own  the  design  and  the  com¬ 
ponents  required  to  assemble  the  system.  The  contractor  will  also  have  to  develop  the  software 
capabilities  necessary  for  consolidation.  The  government  intends  to  own  the  data  rights  for 
future  integration  implementation. 

Figure  2.2  shows  the  vision  for  CANES  as  enabled  by  the  CCE.  Currently,  each  oper¬ 
ating  system  has  its  own  server.  In  the  future,  a  virtual  server  will  enable  multiple  operating 
systems  to  run  on  a  single  server.  This  process  of  “virtualization”  using  service- oriented  archi¬ 
tectures  will  consolidate  many  computing  functions  on  a  common  network  and  set  of  servers. 
The  Navy  expects  that  this  will  allow  for  less  expensive  and  easier  upgrades  in  the  future  and 
commonality  across  the  fleet. 

Software  and  Services 

Multiple  levels  of  software  are  required  for  CANES.  The  virtualization  software  discussed 
above  allows  seemingly  incompatible  systems  to  run  on  a  single  server.  Different  operating  sys¬ 
tems  (e.g.,  Linux,  Solaris,  Windows)  will  be  able  to  run  on  the  same  hardware  and  server.  All 
of  the  applications  that  are  supported  by  each  operating  system  will  also  be  available  on  a  single 
server.  The  challenge  will  be  to  develop  the  virtual  environment  in  a  way  that  allows  all  these 
disparate  systems  and  programs  to  run  on  a  single  server  in  an  efficient  way. 

The  services  or  applications  (e.g.,  email,  voicemail,  videoconferencing)  used  by  the  fleet 
will  be  hosted  on  the  CANES  CCE  hardware  infrastructure.  Many  different  services  and 
applications  are  owned  by  numerous  stakeholders,  not  all  of  them  in  PEO  C4I.  Coordination 
of  the  development  of  the  CCE  with  existing  and  future  customers,  some  of  whom  are  cur¬ 
rently  unknown,  is  a  real  challenge.  The  CANES  program  office  has  identified  an  initial  core 

Figure  2.2 

Common  Computing  Environment 
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set  of  37  applications  but  indicates  that  considerably  more  applications  are  currently  being  used 
in  the  fleet.  The  GFE  software  furnished  to  the  development  contractors  is  based  on  three  of 
the  37  core  applications  identified  by  the  program  office.  The  integration  of  current  and  future 
services  within  the  CCE  is  a  key  challenge  and  will  be  critical  to  the  success  of  CANES. 


Program  Objectives 

In  January  2009,  the  CANES  program  Acquisition  Strategy  stated  four  main  objectives  (Pro¬ 
gram  Manager,  Tactical  Networks,  2009a).  They  were  (1)  consolidate  and  reduce  the  number 
of  afloat  networks  through  the  use  of  mature  cross-domain  technologies  and  CCE  infrastruc¬ 
ture;  (2)  reduce  the  infrastructure  footprint  and  associated  costs  for  hardware  afloat;  (3)  provide 
increased  reliability,  application  hosting,  and  other  capabilities  to  meet  current  and  projected 
Warfighter  requirements;  and  (4)  federate  Net-Centric  Enterprise  Services  (NCES)  service- 
oriented  architecture  (SOA)  core  services  to  support  migration  of  DoD  C4ISR  applications 
to  a  SOA  environment.  An  October  2009  revision  of  the  Acquisition  Strategy  added  a  fifth 
objective,  “provide  a  secure  afloat  network  required  for  Naval  and  Joint  Operations”  (Program 
Manager,  Tactical  Networks,  2009b). 

While  the  Acquisition  Strategy  could  be  revised  in  the  future,  technology  limitations 
could  place  the  current  objectives  at  odds  with  one  another.  Consolidation  of  networks  (Goal  1) 
could  be  at  odds  with  the  security  goal  (Goal  5)  and  the  reliability  goal  (Goal  3).  We  discuss 
these  issues  in  Chapter  Three. 

The  October  2009  Acquisition  Strategy  and  a  briefing  developed  by  the  Navy’s  Program 
Manager,  Warfare  Tactical  Networks  (PMW  160)  (Beel,  2009)  also  identified  several  program 
goals  and  objectives,  including 

•  competition 

•  use  of  small  businesses 

•  use  of  COTS  technology 

•  quick  delivery 

•  cost  reduction. 

While  some  programs  have  been  successful  in  meeting  the  challenge  of  improved  capa¬ 
bility  at  reduced  cost  delivered  quickly,  others  have  found  a  need  to  sacrifice  one  or  another 
of  these  goals.  For  the  CANES  program,  schedule  and  cost  are  the  primary  considerations. 
The  acquisition  strategy  calls  for  the  delivery  of  an  acceptable  increment  of  capability  meeting 
defined  cost  and  schedule  objectives,  consistent  with  the  principles  of  evolutionary  acquisition. 
The  cost  goals  are  expected  to  be  met  through  system  consolidation,  continuous  competition, 
and  use  of  COTS  technology. 


Acquisition  Strategy 

The  CANES  program  also  embodies  a  business  strategy.  It  is  adopting  an  acquisition  approach 
in  which  new  capabilities  are  introduced  incrementally  throughout  the  life  of  the  program 
consistent  with  the  DoD  5000  principles  of  incremental  acquisition.  The  program  decouples 
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hardware  and  software,  giving  the  government  and  application  developers  greater  agility.  Pro¬ 
gram  documentation  that  describes  the  risks  of  the  program  indicates  that  the  success  of  the 
program  will  be  determined,  to  a  large  degree,  by  the  ability  to  integrate  the  hardware  and 
software  upgrades.  Program  success  will  also  depend  on  the  ability  to  manage  the  technology- 
insertion  upgrades  and  configuration  baselines;4  many  application  owners  will  need  to  house 
their  applications  on  CANES.  CANES  not  only  consolidates  the  technical  or  physical  aspects 
of  existing  programs,  it  also  consolidates  the  programmatics  and  infrastructure  of  existing  pro¬ 
grams,  streamlining  the  acquisition  process  by  reducing  the  documentation,  integration,  and 
testing  requirements.  The  use  of  interface-control  documents  will  be  very  important. 

The  CANES  acquisition  strategy  depends  on  an  update  cycle  of  four  years  for  hardware 
and  two  years  for  software.  These  scheduled  baselines  are  intended  to  assist  developers  by 
providing  known  and  predictable  technology  and  software  insertion  points  while  also  offer¬ 
ing  an  architecture  that  mitigates  end-of-life  (EOL)  and  supportability  issues.  As  mentioned 
above,  the  CANES  program  office  is  currently  planning  for  37  C4ISR-related  applications  to 
be  included  in  the  initial  FD  version  that  will  be  fielded  to  the  fleet.  In  the  time  it  will  take 
to  refit  existing  ships  with  CANES,  several  two-year  software  updates  will  have  taken  place. 

The  CANES  program  office  plans  to  work  closely  with  other  stakeholders  in  PEO  C4ISR 
to  field  an  initial  software  and  hardware  baseline  that  can  support  all  CANES  applications. 
Once  the  initial  version  of  CANES  is  deployed,  the  program  office  will  continue  to  work  with 
other  stakeholders  to  ensure  that  software  and  hardware  upgrades  take  place  on  schedule  and 
to  a  standard  that  will  meet  the  needs  of  the  fleet.  Backward  compatibility  considerations  will 
be  very  important.5 

The  two  contracts  the  CANES  program  has  let  to  Northrop  Grumman  and  Lockheed 
Martin  for  the  system  design  and  development  (SDD)  of  the  CCE  were  Cost  Plus  Incentive 
Fee  contracts  for  $15  million  each.  The  Navy  held  preliminary  design  reviews  in  summer 
2010  and  scheduled  critical  design  review  for  October  2010.  At  the  time  of  this  research,  the 
Navy  expected  that  a  down-select  would  occur  in  late  spring  2011. 6  After  the  down-select,  a 
single  designer  was  to  take  the  program  through  the  LD  phase.  At  the  time  this  research  was 
conducted,  the  Navy  anticipated  seeking  bids  for  an  FD  contract  in  spring  2012.  The  Navy 
expected  that  the  designs  produced  during  system  development  will  be  build-to-print,  based 
on  the  system  configuration  developed  in  SDD  and  tested  and  refined  during  low-rate  initial 
production  (LRIP).  The  Navy  expects  that  the  CANES  program  will  then  be  able  to  leverage 
a  much  broader  production  base  in  seeking  contract  proposals  for  full  deployment. 


CANES  Program  Functions  in  Full  Deployment 

Development  of  the  first  increment  of  CANES  will  be  finished  prior  to  the  start  of  FD.  The 
first  increment  will  be  the  largest;  subsequent  increments  are  expected  to  be  smaller  in  scope. 
As  a  result,  once  FD  begins,  production,  installation,  and  software  integration  will  be  the 


4  A  baseline  is  an  established  architecture  for  software  and  hardware  interdependencies.  The  number  of  baselines  has  not 
yet  been  determined. 

5  Growth  in  the  program  is  expected  to  be  managed  by  a  board  of  stakeholders  that  reviews  new  requirements  and  must 
approve  them  for  CANES. 

6  As  of  December  12,  2011,  a  down-select  had  not  taken  place. 
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major  activities  of  the  CANES  program.  The  initial  fielding  of  CANES  will  be  a  significant 
undertaking.  In  some  cases,  the  ship’s  cabling  will  have  to  be  replaced,  requiring  significant 
industrial  work.  The  current  plan  is  to  have  the  initial  ship-sets  outfitted  with  CANES  within 
six  years.  Once  a  ship  is  outfitted,  a  technology  update  cycle  will  begin.  Hardware  will  be 
replaced  every  four  years,  and  software  will  be  updated  at  least  every  two  years.  We  briefly 
describe  below  the  major  program  functions  in  FD  that  the  acquisition  and  contract  strategy 
must  accommodate. 

The  CANES  program  office  identified  some  of  the  required  functions.  The  Program 
Office  developed  an  SDD  statement  of  work  with  an  option  for  one  year  of  FD  performance. 
This  option  describes  three  main  functions  for  the  FD  phase  of  work:  production,  engineering 
support,  and  engineering  design.  The  program  office  intends  to  construct  a  new  statement  of 
work  for  the  FD  phase  of  the  program.  As  a  result,  current  descriptions  include  only  a  portion 
of  the  work  that  will  actually  need  to  be  performed  in  FD.  RAND  researchers,  through  review 
of  program  documentation,  discussion  with  program  staff,  and  analysis  of  other  programs, 
identified  additional  program  functions,  as  discussed  below. 

Production 

After  the  first  increment  is  complete,  the  Navy  expects  that  one  or  more  organizations  will 
fabricate,  integrate,  test,  and  deliver  the  CANES  system.  The  organization^)  will  be  expected 
to  provide  workstations  and  peripherals  to  support  the  delivered  system.  Other  possible  respon¬ 
sibilities  might  include  loading  government-furnished  software. 

System  Testing 

A  number  of  testing  activities  will  occur  throughout  the  life  of  the  program  as  hardware  and 
software  are  updated.  There  will  need  to  be  testing  of  the  CCE  and  its  applications,  of  CCE 
and  application  integration,  and  then  operational  testing  for  each  new  update.  In  the  SDD 
phase  of  the  CANES  program,  the  contractors  are  responsible  for  testing  the  CCE  equipment 
against  government  specifications.  The  application  providers  are  responsible  for  ensuring  that 
their  applications  can  run  on  the  CCE.  The  government  is  responsible  for  the  integration 
testing. 

Once  the  CCE  is  delivered,  but  prior  to  installation,  verification  and  validation  of  the 
equipment  will  occur  at  the  vendor  site  and  be  performed  by  the  In-Service  Engineering  Agent 
(ISEA).  This  agent  is  part  of  the  Space  and  Naval  Warfare  Systems  Command  (SPAWAR)  and 
is  independent  from  the  contractor  and  the  program  office.  The  CANES  program  office  is 
establishing  a  lab  to  perform  the  integration  testing  of  independently  developed  hardware  and 
software.  The  contractor  will  be  responsible  for  providing  equipment  to  the  lab.  During  FD, 
the  lab  could  continue  developing  software  applications  and  testing  their  integration. 

System  Installation 

The  program  offices  within  PEO  C4I  procure  the  equipment  to  be  installed  on  the  ship.  The 
modernization  process  is  complex,  involving  many  organizations  outside  the  PEO.  The  plan¬ 
ning  for  modernizations  begins  two  years  prior  to  the  start  of  the  work,  when  a  Ship  Change 
Document  (SCD)  is  submitted  with  a  limited  description  of  the  system  to  be  installed.  The 
corresponding  platform  Program  Manager  Warfare  (PMW)  will  then  review  and  submit  the 
work  order  to  a  database  (Navy  Data  Environment)  so  that  it  can  be  reviewed  in  a  process  used 
to  prioritize  and  execute  modernizations  (referred  to  as  SHIPMAIN).  There  are  three  main 
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phases  of  approvals  as  the  installation  date  nears,  and  the  level  of  detail  regarding  the  instal¬ 
lation  increases  at  each  phase.  The  system  may  require  several  certifications  involving  outside 
organizations.  SPAWAR  System  Centers  (SSCs)  or  contractors  must  engage  with  the  Naval 
Surface  Warfare  Center,  Carderock  Division,  to  receive  necessary  shock  and  vibration  certifica¬ 
tions.  SPAWAR  determines  whether  certain  cyber  security-related  certifications  are  required. 
An  In-Service  Logistics  Support  certification  must  be  submitted  by  the  Naval  Sea  Systems 
Command  (NAVSEA).  NAVSEA  will  ultimately  approve  the  installation  and  provide  a  letter 
of  authorization  for  installation. 

Every  ship  has  a  shipyard,  referred  to  as  its  planning  yard,  responsible  for  planning  its 
maintenance.  Approximately  15  months  prior  to  installation,  the  planning  yard  is  notified  of 
the  plan  to  install  equipment.  When  funding  and  the  ship  are  available,  the  planning  yard  will 
inspect  the  ship  and  produce  a  Ship  Installation  Document  (SID)  that  has  drawings  of  the 
ship  with  details  required  for  the  installation  team.  It  may  be  several  months  before  the  docu¬ 
ments  are  delivered  to  the  Installation  Management  Office  (IMO),  the  SPAWAR  organization 
responsible  for  coordinating  the  installation  with  the  shipyard,  and  the  actual  contractors  who 
perform  the  installation,  or  the  Alteration  Installation  Team  (AIT).  Because  many  activities 
are  typically  being  performed  during  a  ship’s  maintenance  availability,  all  are  managed  by  the 
fleet’s  Regional  Maintenance  Center  (RMC).  IMO’s  Ship  Supervisor  (SHIPSUP)  manages  the 
overall  SPAWAR  effort  during  the  availability.  Daily  production  meetings  are  held  with  the 
RMC,  AITs,  IMO,  SHIPSUP,  and  the  ship’s  force  and  shipyard  personnel  to  discuss  work  pri¬ 
orities  and  assignment  of  resources. 

Personnel  involved  with  installation  activities  are  invited  to  examine  equipment  when  it 
arrives  at  the  staging  area.  The  ship’s  force  is  expected  to  help  transfer  data.  The  application 
owners  will  determine  who  will  install  the  applications  during  the  staging.  The  application 
owners  also  have  an  ISEA. 

Design  Services 

As  technology  evolves,  further  design  may  be  required.  This  could  include  developing  integra¬ 
tion  work  or  new  baselines  and  drawings  for  platforms  that  were  not  in  the  initial  design  pool. 
The  designer  may  need  to  provide  technical  support  for  other  functions,  such  as  system  and 
application  integration,  installation,  and  testing. 

The  organization  providing  design  services  may  also  support  the  development  of  techni¬ 
cal  reports  and  studies  on  new  and  emerging  technologies,  noncritical  problems,  and  other 
CANES-specific  technology  areas  needing  further  analysis,  such  as  how  to  facilitate  and  real¬ 
ize  the  integration  of  the  CCE  and  applications.  Given  intimate  knowledge  of  the  system  and 
its  workings,  the  designer  may  also  need  to  participate  in  logistics  and  support  activities,  such 
as  the  development  of  technical  and  support  manuals. 

Systems  Engineering  and  Integration 

Systems  engineering  and  integration  is  a  key  CANES  activity.  Other  program  personnel  have 
described  system  engineering  and  integration  as  an  extremely  challenging  task,  the  focus  of 
which  is  the  design,  management,  and  execution  of  the  integration.  Essentially,  the  integrator 
is  responsible  for  getting  the  system  to  “work.”  The  integrator  may  need  to  develop  interfaces, 
including  “glue” — the  virtualization  that  is  required  to  integrate  the  CCE  and  the  various 
applications.  The  integrator  may  need  to  work  with  the  developers  and  production  to  resolve 
integration  challenges.  The  integrator  should  have  a  long-term  relationship  with  the  govern- 
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ment  because  the  accumulated  knowledge  and  expertise  required  to  perform  integration  activi¬ 
ties  is  difficult  to  replace.  There  will  also  be  a  continuous  need  for  hardware  and  software 
integration  as  the  system  is  updated.  The  integrator  might  design  and  update  standards  and 
protocols  for  the  integration  of  applications. 

Configuration  Management 

As  various  ships  receive  hardware  and  software  updates,  there  will  be  many  configurations  in 
the  fleet.  Ensuring  that  all  ships  have  the  correct  hardware  and  software  baselines  could  be  a 
very  challenging  task.  It  entails  developing  a  detailed  recording  and  updating  of  information 
that  describes  the  hardware  and  software,  including  the  recording  of  versions  and  updates  that 
have  been  installed.  It  also  requires  tracking  and  managing  hardware  and  software  updates  by 
ship. 

In-Service  Support 

Once  the  system  is  installed,  there  will  likely  be  a  need  for  system  support.  While  the  update 
rate  is  designed  to  address  obsolescence  issues  and  minimize  the  amount  of  support  required, 
hardware  or  software  failures  should  be  expected.  When  these  failures  occur,  the  designer, 
integrator,  or  production  organization  might  need  to  assist  the  government.  The  technical  data 
and  documentation  required  to  support  the  system  will  have  been  provided  to  the  government 
so  that  the  government  might  address  the  problem.  There  are  many  options  for  providing  this 
support.  A  facility,  staffed  by  government  or  contractor  personnel,  may  be  set  up  to  provide 
such  support.  Alternatively,  existing  facilities  may  provide  support. 

The  Navy  has  included  incentives  to  use  COTS,  Government  Off-The-Shelf,  or  other 
open  standards  in  system  development  so  as  to  facilitate  updates  and  reduce  life-cycle  costs. 
The  Navy  is  expecting  a  system  design  that  will  maximize  its  ability  to  accommodate  the  fast 
pace  of  change  experienced  in  the  commercial  sector.  Upgrading  the  hardware  on  a  four-year 
cycle  and  the  software  on  a  two-year  cycle  is  expected  to  minimize  technical  obsolescence 
issues,  which  can  lead  to  significant  life-cycle  costs. 

Governance 

Numerous  organizations  require  network  services  afloat  and  are  able  to  procure  supporting 
hardware  and  software.  Some  of  these  organizations,  such  as  the  Intelligence  Agencies,  are  out¬ 
side  the  Navy.  In  order  to  consolidate  networks  and  obtain  C4I  commonality  across  the  fleet, 
the  Navy  will  require  some  form  of  governance  for  the  CANES  system.  Top  Navy  leadership 
will  need  to  ensure  that  CANES  is  used  to  the  maximum  extent  possible  to  meet  the  needs  of 
varying  organizations.  In  December  2009,  the  Chief  of  Naval  Operations  sent  a  message  to 
all  potential  stakeholders  establishing  a  CANES  Oversight  Review  Board,  whose  responsibili¬ 
ties  are  to  integrate  “appropriate  existing  Navy  .  .  .  processes  for  the  Consolidation  of  afloat 
networks  and  migration  of  applications  and  systems  into  the  CANES  [and  to]  approve  any 
networks,  applications,  and/or  systems”  that  would  operate  on  CANES  following  installa¬ 
tion  (CNO,  2009).  Systems  that  will  not  use  the  CANES/CCE  infrastructure  do  not  need  to 
be  approved  by  the  board.  This  concerned  some  of  our  interviewees,  who  said  that  without  a 
higher  level  of  governance,  additional  systems  will  be  put  on  the  ship,  thereby  minimizing  the 
desired  effects  of  CANES. 
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Grouping  CANES  functions  can  help  in  developing  contracting  options.  There  are  many 
potential  ways  to  group  CANES  functions.  Each  function  requires  a  specific  set  of  skills.  Pro¬ 
duction  requires  procurement,  assembly,  testing,  and  shipping  skills.  Installation  requires  ship¬ 
engineering,  logistic,  and  ship-alteration  skills.  Design  services  require  IT  and  logistics  skills. 

For  purposes  of  this  analysis,  we  aggregated  the  functions  to  be  performed  during  the  FD 
phase  of  the  CANES  program,  based  on  the  similarity  of  the  skills  and  the  time  frame  that 
exercise  of  these  skills  may  require  for  providing  best  value  to  the  government.  For  example, 
some  functions  may  be  better  performed  if  a  long-term  relationship  exists  between  the  govern¬ 
ment  and  contractor,  so  we  grouped  those  activities  accordingly.  The  result  was  three  func¬ 
tional  categories. 

•  Technical:  advice,  design,  systems  engineering  and  integration,  configuration  manage¬ 
ment,  in-service  support,  and  other  efforts  requiring  engineering,  technical,  or  IT  sup¬ 
port  for  the  hardware  and  software  systems.  These  skills  are  best  employed  in  a  long-term 
relationship  with  the  program  office  to  maintain  continuity  and  consistency  and  to  maxi¬ 
mize  benefit  of  feedback  from  the  field. 

•  Production:  acquisition,  assembly,  and  wiring  of  hardware  racks;  installation  of  software 
and  kitting  necessary  to  prepare  ships  for  installation.  With  well-defined  specifications, 
these  skills  can  be  periodically  employed  through  competitive  contracts  for  up  to  one 
year’s  worth  of  hardware  and  services. 

•  Installation:  all  effort  necessary  to  plan,  document,  accomplish,  test,  and  accept  the 
installation  of  CANES  systems  on  warships.  These  skills  require  a  long-term  relationship 
with  the  program  office  in  order  to  perform  the  two  years  of  planning  necessary  for  the 
SHIPMAIN  process  prior  to  installation. 


Criteria  for  Developing  Procurement  Approaches 

For  the  full  deployment  of  CANES,  we  sought  governing  principles  that  would  be  flexible 
enough  to  accommodate  changes  in  the  following: 

•  Technology:  Moore’s  Law  will  mean  constant  changes  in  commercially  available  hard¬ 
ware  over  the  life  of  the  CANES  program. 

•  Requirements:  CANES  software  applications  will  also  change  continually. 
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•  Schedule:  The  schedule  for  installing  CANES  systems  on  every  warship  in  the  fleet  will 
change  as  ship  availabilities  change  due  to  myriad  operational,  maintenance,  and  fund¬ 
ing  issues. 

Moreover,  the  options  need  to  provide  the  best  technical,  production,  and  installation 
value  for  the  government.  While  price  is  always  an  important  consideration,  best  value  is  criti¬ 
cal  for  the  CANES.  If  the  hardware,  software,  or  installation  process  does  not  work  properly, 
a  warship  may  not  be  operational,  negating  any  procurement  savings.  Even  a  delay  in  instal¬ 
lation  could  keep  a  ship  in  a  shipyard  longer  than  necessary,  with  associated  additional  costs. 
The  program  must  achieve  a  balance  between  price  and  quality. 


Governance  Options 

An  acquisition  strategy  should  first  determine  the  role  the  government  will  perform  in  execut¬ 
ing  the  program.  If  the  government  could  write  a  complete,  detailed  specification  ensuring 
that  it  will  receive  what  it  needs,  it  could  turn  all  governance  over  to  industry  and  inspect  and 
accept  the  CANES  installation  at  the  end  of  the  process.  Alternatively,  the  government  could 
control  all  aspects  of  the  acquisition  and  hire  support  contractors  to  provide  resources  used 
under  government  direction  while  maintaining  performance  of  inherently  governmental  func¬ 
tions.1  A  middle  role  for  government  involvement  appears  ideal  for  the  CANES  program.  This 
option  provides  government  oversight  while  assigning  tasks  to  organizations  most  qualified  to 
perform  them.  In  developing  procurement  options,  we  assume  the  government  will  take  such 
a  role.  Specifically,  we  assume  that  the  government  will 

•  make  major  program  decisions  for  CANES 

•  maintain  responsibility  for  development  and  ownership  of  requirements,  program  man¬ 
agement,  and  testing 

•  maintain  technical  authority 

•  create  an  integration  strategy  that  assigns  roles  and  responsibilities  to  various  parties 

•  support  and  determine  the  future  direction  of  the  program. 


Procurement  Options 

The  five  procurement  options  we  developed  cover  two  opposite  strategies  and  three  variants 
that  fall  in  between.  The  two  opposing  strategies  are  (1)  maximizing  as  much  of  the  effort  as 
possible  under  one  prime  contract  or  (2)  performing  as  much  effort  as  possible  using  existing 
government  resources. 

The  three  intermediate  options  involve  different  mixes  of  multiple  contractor  and  govern¬ 
ment  resources.  The  five  options  developed  for  analysis  are  presented  in  Table  3.1. 


1  The  Federal  Activities  Inventory  Reform  Act  (RL.  105-270)  defines  an  inherently  governmental  function  as  “a  function 
that  is  so  intimately  related  to  the  public  interest  as  to  require  performance  by  Federal  Government  employees.”  Such  an 
approach  would  likely  violate  the  Federal  Acquisition  Regulation  (FAR)  (37.104[b])  prohibition  on  personal  service  con¬ 
tracts  and  blur  responsibility  for  performance,  but  is  noted  here  to  help  delineate  the  range  of  options  the  government  might 
consider. 
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Table  3.1 

Procurement  Options 


Option 

Function 

Single  Prime 
Contractor 

Multiple  Contract 
Model  A 

Multiple  Contract 
Model  B 

Multiple  Contract 
Model  C 

Government 

Design  and 
integration 

Technical  advice 

Systems 

engineering 

Configuration 

management 

In-service 

support 

Prime 

Contractor  A 

Contractor  A 

Contractor  A 

Government 

Production 

Prime 

Winners  of 
production 

MAC  IDIQ  (not 
Contractor  A) 

Winners  of 
production 

MAC  IDIQ  (not 
Contractor  A) 

Winners  of 
production 

MAC  IDIQ  (not 
Contractor  A) 

Government 
plus  winners  of 
existing  service 
center  MACs 

Installation 

Prime 

IMO 

Winners  of 
installation 

MAC  IDIQ  (not 
Contractor  A 
or  the  winners  of 
the  production 
MAC  IDIQ) 

Winners  of 
production 

MAC  IDIQ  (not 
Contractor  A) 

IMO 

NOTES:  IDIQ  =  indefinite  delivery,  indefinite  quantity.  IMO  =  Installation  Management  Office.  MAC  =  multiple- 
award  contract. 


A  Single  Prime  Contractor 

A  single  prime  contractor  is  the  acquisition  model  most  commonly  used  in  the  Department 
of  Defense.  Under  this  acquisition  model,  a  single  organization  is  responsible  for  the  design, 
production,  and  sometimes  the  in-service  support  of  the  system.  While  the  prime  contractor 
may  subcontract  or  partner  with  others,  the  government  deals  directly  with  the  single  prime 
as  the  responsible  party. 

When  using  a  single  prime  contractor,  the  government  may  use  one  prime  contract,  requir¬ 
ing  multiple  contract  line  items  numbers  (CLINs)  to  accomplish  all  FD  functions  over  several 
years.  The  CLINs  would  require  different  contract  types  and  work  scopes  (e.g.,  cost-plus-fixed- 
fee  or  firm-fixed-price  [FFP],  some  with  completion  work  scopes  and  others  with  level-of-effort 
[LOE],work  scopes2)  to  operate  effectively.  Some  CLINs  will  likely  have  to  allow  delivery  and 
task  orders3  to  be  negotiated  and  awarded  subsequent  to  prime  contract  award,  given  that 
hardware-production  baselines  and  installation  schedules  for  ships  receiving  CANES  in  future 


2  A  completion  work  scope  describes,  in  detail,  everything  necessary  to  perform  the  job.  A  LOE  work  scope  loosely 
describes  what  needs  to  be  done  in  a  specified  number  of  hours.  An  LOE  work  scope  can  be  used  in  either  a  cost  or  fixed- 
price  contract.  If  used  in  a  fixed-price  contract,  the  hourly  rates  are  locked,  but  more  hours  must  be  added  if  the  work  is 
not  completed. 


In  federal  procurement  terminology,  delivery  orders  buy  supplies  and  task  orders  buy  services  under  previously  awarded 


contracts. 
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years  cannot  be  specified  today.4  A  notional  CLIN  schedule  for  a  single  prime  contract  might 
include  the  following: 

•  CLIN  001  Provide  technical  advice  to  PMW  160 

-  This  would  be  a  cost-plus  (CP)  LOE  with  task  orders  (TOs)  having  a  CP  or  fixed-price 
(FP)  basis  for  studies  and  analyses. 

•  CLIN  002  System  Engineering  and  Integration 

-  CP  LOE  with  TOs  (CP  or  FP)  for  studies  and  analyses 

•  CLIN  003  Configuration  Management 

—  CP  LOE  or  completion  scope  of  work 

•  CLIN  004  Production 

-  Firm  FP  delivery  orders  (DOs) 

•  CLIN  005  Installation 

—  CP  TOs  or  FFP  TOs  with  many  changes 

•  CLIN  006  In-service  support 

-  CP  LOE  or  time  and  material  work  scope 

These  recommendations  are  derived  from  basic  contract  principles.  Where  the  level  of 
required  effort  is  unknown  or  risks  are  high,  a  CP  contract  is  suggested.  If  the  price  and 
amount  of  work  is  known,  then  a  FP  contract  is  suggested. 

Although  this  single  prime  contract  could  be  competitively  awarded  based  on  best  value, 
such  a  competition  would  not  be  meaningful.  This  is  because  some  CLINs  would  have  LOE 
work  scope  for  which  the  government  must  pay  whatever  it  takes  to  complete  the  work,  whereas 
other  CLINs  would  also  require  subsequent  sole-source  negotiation  of  numerous  changes  or 
TOs  and  delivery  orders  (DOs)  with  the  prime  contractor. 

A  prime  contractor  model  would,  however,  have  the  following  advantages: 

•  Only  one  contractor  would  be  responsible  for  program  performance. 

•  Contractor-coordination  efforts  would  be  minimized. 

•  There  would  minimal  need  for  government-furnished  information  (GFI)  or  GFE,  reduc¬ 
ing  the  government’s  liability  for  contract  changes  or  disputes. 

•  Using  one  contractor,  and  hence  consistent  standards  and  communication  protocols,  can 
reduce  technical  risk. 

The  one  prime  contractor  model  has  several  disadvantages. 

•  Much  of  the  dollar  value  of  the  prime  contract  would  be  negotiated  with  the  prime  con¬ 
tractor  after  contract  award  on  a  sole-source  basis, 5  when  the  government  has  no  com¬ 
petitive  leverage. 


4  According  to  Department  of  the  Navy,  2010,  less  than  one-fifth  of  the  money  needed  to  procure  and  install  CANES 
hardware  will  be  funded  in  FY  2012,  when  a  full  deployment  contract  is  assumed  to  be  awarded.  With  constantly  chang¬ 
ing  production  baselines  and  installation  schedules,  future-year  production  and  installation  requirements  will  require  sole- 
source  negotiation  of  (a)  changes,  if  out-year  production  and  installation  are  prepriced,  or  (b)  new  delivery  and  task  orders 
as  production  baselines  and  schedules  are  updated. 

5  According  to  Program  Manager,  Tactical  Networks,  2010,  more  than  82  percent  of  the  program’s  total  funding  is  pro¬ 
curement  funding,  with  the  rest  being  research,  development,  test,  and  evaluation  (RDT&E)  and  Operations  and  Main- 
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•  The  one  prime  contractor  model  will  require  intense  Navy  effort  to  negotiate  many  TOs, 
DOs,  and  contract  changes  in  a  sole-source  environment. 

•  Once  the  prime  contract  is  awarded,  the  government  will  have  fewer  tools  to  manage 
performance  or  costs. 

•  The  one  prime  contractor  model  would  require  new  processes  and  agreements  with  instal¬ 
lation  activities  (e.g.,  planning  yards,  RMCs,  private  shipyards)  that  currently  deal  with 
the  SPAWAR  IMO  to  install  ship  alterations. 

Multiple  Contract  Model  A 

Model  A  uses  different  contracts  for  different  functions.  It  uses  one  contract  to  provide  the  nec¬ 
essary  technical  and  engineering  effort,  including  design  and  integration.  This  contract  can  be 
competitively  awarded  but  must  cover  multiple  years  to  ensure  continuity  and  avoid  disruptive 
and  costly  contractor  turnover.  The  CLINs  would  be  mostly  cost-plus,  LOE  scopes  with  some 
TO  provisions  for  the  contractor  to  address  technical  requirements  and  schedule  changes  that 
cannot  be  managed  through  FP  contracts.  The  FD  production  effort  in  this  model  would  be 
carried  out  by  contractors  receiving  periodic  MAC  IDIQ  awards  as  prescribed  in  FAR  Subpart 
16.5.* * *  6  The  MAC  contracts  would  be  competitively  awarded  to  several  contractors  that  would 
compete  periodically  to  deliver  one  or  more  ship-sets  of  CANES  equipment  ready  for  ship¬ 
ment  to  the  warship  installation  site.  The  installation  would  be  handled  by  the  SPAWAR  IMO, 
which  would  use  AIT  contractors,  experienced  in  shipyard  work,  to  install  the  systems. 

Model  A  offers  several  advantages: 

•  One  contractor  performing  all  engineering  functions  and  maintaining  continuous  expe¬ 
rience  over  long  terms.  This  minimizes  the  cost  associated  with  changing  contractors  as 
well  as  the  risk  to  integration  of  engineering  products. 

•  Periodic  FFP  competitions  for  production  ship-set  delivery  orders.  This  would 

-  help  obtain  current  best  prices  for  hardware  to  facilitate  production  baseline  updates 
without  negotiating  changes  due  to  late  or  defective  GFI  or  GFE 

-  allow  past  performance  to  be  competition  for  future  delivery  orders,  thereby  providing 
incentives  for  current  performers  to  provide  quality  and  timely  performance 

•  Use  of  existing  organization,  contractors,  and  processes  for  the  complex  installation 
process. 

The  disadvantages  of  the  Model  A  option  are  that  it  requires  multicontractor  competi¬ 
tions,  awards,  and  coordination  by  the  program  office  as  well  as  program  manager  assumption 
of  responsibility  for  meeting  system  requirements  and  provision  of  GFE  and  GFI.7  This  may 
require  negotiating  contract  changes,  thus  making  it  harder  to  hold  contractors  responsible  for 


tenance,  Navy  (O&M.N).  As  previously  noted,  only  18.5  percent  of  the  program’s  procurement  funds  are  budgeted  for  FY 

2012.  The  vast  majority  of  the  program’s  procurement  and  installation  funding  occurs  in  subsequent  years  when  production 

baselines  and  installation  schedules  are  continuously  changing. 

6  We  cannot  comment  on  how  successful  IDIQ  contracts  have  been  in  other,  similar  programs. 

7  For  example,  the  hardware  delivered  by  the  production  contractor  will  become  GFE  to  IMO’s  alteration  installation 


contractor. 
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their  performance.  Moreover,  there  is  some  concern  that  the  IMO  process  may  not  obtain  the 
lowest  cost  for  installation.8 

Multiple  Contract  Model  B 

Model  B  is  similar  to  Model  A  in  that  it  uses  one  competitively  awarded,  long-term  contract 
for  the  engineering  effort  and  competitive  MAC  IDIQ  delivery  orders  for  production  of  ready- 
to-install  CANES  ship-sets.  It  differs  from  Model  A  in  that  it  would  use  a  separate  set  of  MAC 
IDIQ  contracts  for  ship  installations. 

This  approach  has  the  same  advantages  as  Model  A  and  the  additional  advantage  of  peri¬ 
odic  competitions  for  installation  task  orders,  giving  the  government  some  leverage  for  improv¬ 
ing  cost,  schedule,  and  quality. 

The  Model  B  option  also  has  the  same  disadvantages  as  Model  A.  It  has  the  additional 
disadvantage  of  requiring  extra  government  effort  to  set  up  and  administer  two  sets  of  MAC 
contracts.  Like  the  one-prime-contract  model,  it  would  require  new  processes  and  agreements 
to  coordinate  with  planning  yards,  type  commanders,  RMCs,  shipyard  contractors,  and  others. 
Navy  and  SPAWAR  policy  may  also  need  to  be  modified  to  allow  such  transactions.9 

Multiple  Contract  Model  C 

The  Model  C  multiple  contract  option  uses  the  same  competitively  awarded,  long-term  con¬ 
tract  approach  as  Models  A  and  B.  It  differs  in  its  use  of  one  set  of  MAC  IDIQ  contracts  to 
combine  CANES  production  and  installation.  It  would  hold  periodic  competitions  between 
the  MAC  contractors  for  combined  DOs  and  TOs  to  produce  and  install  CANES.  The  DO 
CLIN  would  be  FFP  and  the  corresponding  installation  TO  CLIN  would  initially  be  cost  plus 
incentive  fee.  As  installation  experience  was  gained,  installation  task  orders  could  shift  to  a 
fixed  price  incentive  (FPI)  CLIN. 

This  approach  has  all  the  advantages  of  Model  B.  It  has  the  additional  advantage  of  hold¬ 
ing  one  contractor  responsible  for  each  ship.  It  also  has  all  the  disadvantages  of  Model  B.  It  has 
the  additional  disadvantage  that  the  IDIQ  awards  would  likely  exceed  $10  million,  thereby 
permitting  MAC  bid  protests  under  the  FAR. 

Maximum  Government  Performance 

The  last  option  is  in  many  ways  the  opposite  of  the  first  mentioned,  that  of  maximum  govern¬ 
ment  performance.  Under  this  approach,  the  technical  and  engineering  functions  would  be 
assigned  to  the  SSCs,  the  IT  hardware  would  be  procured  using  existing  government  MACs, 
and  the  IMO  would  handle  the  installation  using  existing  processes  and  AIT  MACs. 


8  Numerous  interviewees  complained  about  the  cost  of  installing  hardware  on  warships  during  private-shipyard  availabili¬ 
ties.  Not  all  of  this  cost  is  attributable  to  the  IMO’s  alteration-installation  contractor.  Each  ship  class  has  a  planning  yard 
that  maintains  the  drawings  for  the  ships.  The  IMO  must  pay  the  planning  yard  to  verify  the  ship  configuration  and  modify 
the  drawings  to  accomplish  the  installation.  Moreover,  the  shipyard  performing  the  availability  charges  to  provide  direct 
support  services  (e.g.,  rigging,  welding)  to  the  IMO’s  alteration  installation  contractor.  The  RMC  also  prorates  the  cost  of 
indirect  services  (e.g.,  security,  temporary  power,  ventilation)  provided  by  the  availability  shipyard  to  all  work  performed 
during  the  availability.  All  these  costs  can  be  quite  large  and  variable  and  must  be  paid  regardless  of  whether  the  installation 
is  handled  by  the  IMO  or  a  PMW  160  contractor. 

9  SPAWAR  (2006),  p.  4  states  that  “planning  and  execution  of  installations  shall  be  centralized  in  the  established 
SPAWARSYSCEN  Atlantic  and  SPAWARSYSCEN  Pacific  Installation  Management  Offices.  .  .  .” 
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The  advantages  of  this  model  are  that  it  minimizes  contract  actions,  uses  existing  instal¬ 
lation  processes,  and  provides  the  program  office  with  excellent  oversight. 

There  are  three  principal  disadvantages  to  this  approach.  First,  the  program  office  would 
have  to  compete  for  priority  of  SSC  resources.  Second,  this  approach  would  subject  only  62 
percent  of  its  program  spending  to  competition.10  Third,  the  program  office  would  have  little 
incentive  to  manage  the  performance  of  other  government  organizations.* 11 


10  The  previously  cited  FY  2011  CANES  procurement  budget  (Department  of  the  Navy,  2010)  shows  that,  of  the  $1,455.9 
million  to  be  spent  on  CANES  procurement  from  FY  2010  to  FY  2015,  $353.9  million  would  be  for  installation  and 
$1,102.0  million  would  be  for  production  equipment.  In  this  model,  only  production  equipment  would  be  procured 
through  competitive  contracts.  The  $1,102.0  million  for  production  equipment  is  62.4  percent  of  the  total  program  cost  of 
$1,766.7  million  previously  cited. 

11  One  potential  tool  is  to  allow  the  CANES  program  manager  to  provide  input  to  the  performance  and  promotion  reviews 
of  the  performing  activity. 


CHAPTER  FOUR 


Insights  from  Other  Programs 


CANES  is  an  ambitious  program  that,  if  successful,  will  significantly  consolidate  the  amount 
of  C4I  hardware  and  software  on  board  Navy  ships.  Given  the  number  of  legacy  systems  that 
are  on  board  today’s  ships,  the  process  of  consolidating  older  C4I  applications  will  be  challeng¬ 
ing.  Of  perhaps  equal  importance  will  be  the  one-  to  two-year  software  updates  and  four-year 
hardware  updates  that  the  CANES  program  is  planning.  As  the  CCE  is  updated,  the  Navy 
will  need  to  ensure  that  all  the  applications  running  on  the  system  are  compatible  with  the  new 
hardware.  Integrating  the  inputs  from  multiple  stakeholders  will  be  a  challenging  task. 

Other  programs  within  the  Department  of  Defense  can  offer  some  important  lessons  for 
the  CANES  program.  This  chapter  examines  seven  such  programs.  The  sources  available  to  us 
on  these  programs  had  differing  amounts  of  information,  resulting  in  a  different  presentation 
of  information  for  each  program. 

We  examined  four  programs  in  detail:  the  Air  Force  Mission  Planning  System  (MPS),  the 
Navy  Acoustic  Rapid  COTS  Insertion  (ARCI),  the  Navy  Virginia-c lass  Non-Propulsion  Elec¬ 
tronic  System  (NPES),  and  the  Navy  Common  Submarine  Radio  Room  (CSRR).  We  selected 
these  programs  because  they  are  all  IT  integration  efforts  that  were  not  part  of  the  host  vehicle 
design  and  were  produced  independently  of  the  host  vehicle.  These  programs  also  required  the 
coordination  of  many  producers,  each  responsible  for  a  different  piece  of  the  program.  They 
were  also  considered  by  the  literature  to  be  “successful”  programs  in  that  they  delivered  a 
desired  capability  at  an  acceptable  cost  and  schedule. 

We  also  reviewed  the  Army  Future  Combat  System  (FCS),  the  Coast  Guard  Deepwater 
program,  and  the  Navy  Integrated  Communications  and  Advanced  Networks  (ICAN).  We 
reviewed  these  programs  because  they  had  a  complex  integration  requirement  or  were  employ¬ 
ing  an  open-architecture  approach,  two  key  characteristics  of  the  CANES  program.1 

Some  of  the  programs  reviewed  have  been  considered  “successful,”  meaning  that  the 
desired  capability  was  delivered  on  time  and  within  budget.  Others  have  not  been  considered 
successful.  While  none  of  these  programs  is  identical  to  CANES,  all  offer  useful  insights. 

MPS,  ICAN,  ARCI,  NPES,  and  CSRR  are  similar  to  CANES  in  their  goals  and  chal¬ 
lenges.  These  programs  can  provide  lessons  on  the  magnitude  of  the  integration  challenge. 


1  We  also  based  our  selection  on  the  availability  of  information  regarding  the  program.  For  those  programs  where  we 
were  able  to  gain  greater  insights,  we  provide  additional  program  information  in  Appendix  A  on  the  Mission  Planning 
System,  Appendix  B  on  the  Integrated  Communications  and  Advanced  Networks,  and  Appendix  C  on  Acoustic  Rapid 
COTS  Insertion.  In  some  cases,  we  were  able  to  interview  individuals,  such  as  current  or  past  program  managers,  who  have 
intimate  knowledge  of  the  program.  In  other  cases,  we  only  had  publicly  available  documentation  or  unpublished  RAND 
research  available  to  us. 
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The  contracting  options  developed  for  these  programs  can  also  offer  lessons  for  the  Navy 
CANES  effort.  These  programs  can  help  inform  the  CANES  program  office  concerning 

•  assignment  of  roles  and  responsibilities  for  various  functions 

•  the  most  appropriate  contracting  strategies 

•  top  technical  issues. 


Contracting 

The  NPES  program  consists  of  many  electronic  systems  outside  the  propulsion  plant.  NPES 
has  “sonar  displays  and  processors;  Navigation  and  Combat  Control  Architecture;  Data  Distri¬ 
bution  and  Display,  Electronic  Support  Measures,  Onboard  Team  Trainer;  Total  Ship  Moni¬ 
toring;  and  Submarine  Regional  Warfare  systems  ...  all  electronically  integrated  on  a  rafted 
system  and  inserted  into  the  Virginia  hull”  (Global  Security,  2008).  The  design  was  developed 
separately  from  the  hull  design. 

For  NPES,  a  single  prime  contractor  was  selected:  Electric  Boat  (EB),  which  designed  and 
built  the  Virginia  class.  Successful  delivery  of  NPES  was  the  responsibility  of  the  shipbuilder. 
To  gain  sufficient  IT  expertise  for  this  work,  EB  subcontracted  to  Lockheed  Martin  and  the 
Naval  Undersea  Warfare  Center  (NUWC).  Lockheed  Martin  and  the  NUWC  assisted  with 
system  design,  engineering,  and  integration,  while  Electric  Boat  managed  production  and 
installation. 

MPS  and  ARCI  did  not  have  a  prime  contractor.  Instead,  these  programs  had  multiple 
contracts  for  different  functions. 

MPS  is  a  ground-based  pre-mission  planning  system  for  most  types  of  aircraft  in  the  Air 
Force.  It  is  a  ground  system  executed  on  laptops.  There  is  no  platform  installation  on  board 
aircraft;  mission  planning  data  are  transferred  to  the  aircraft  computers.  MPS  has  three  main 
components: 

•  the  system  framework,  which  performs  basic  mission  planning 

•  the  common  capabilities  (intelligence,  imagery,  refueling)  hardware  (personal  computers 
and  servers  obtained  through  GSA  contracts) 

•  the  platform-unique  planning  components. 

MPS  has  two  main  contracts: 

•  a  long-term  contract  with  a  system  integrator  responsible  for  having  all  pieces  work 
together 

•  an  IDIQMAC  for  the  design  and  production  of  the  software  associated  with  the  common 
capabilities  and  unique  planning  components. 

The  first  contract,  with  the  system  engineering  and  integration  contractor  (SE&IC), 
assigns  the  responsibility  of  providing  a  fully  functioning  system  to  the  Air  Force.  Much  of  the 
material  passed  to  the  SE&IC  is  furnished  by  the  government.  Under  the  MAC,  five  compa¬ 
nies  competed  for  different  work  under  task  orders.  To  maintain  and  refine  the  system  frame¬ 
work,  the  MPS  program  office  has  a  long-term  (12-year)  contract  with  a  single  contractor. 
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A  major  challenge  for  the  MPS  program  is  integrating  multiple  software  applications 
from  offices  for  different  aircraft  throughout  the  Air  Force.  Other  program  offices  that  develop 
weather  or  threat-related  software  also  have  to  integrate  their  applications  into  MPS.  This  is 
very  similar  to  the  challenge  that  CANES  will  face  as  it  receives  applications  from  various 
Navy  C4ISR  stakeholders. 

ARCI  was  a  Navy  initiative  to  improve,  with  a  decreasing  budget,  acoustic  abilities  of 
the  submarine  fleet.  The  program  has  evolved  since  its  inception  in  the  early  1990’s.  There  has 
never  been  a  single  prime  contractor  for  ARCI.  Rather,  as  the  Air  Force  has  had  for  MPS,  for 
ARCI  the  Navy  has  had  one  long-term  relationship  with  a  system  integrator,  Lockheed  Martin, 
and  other  contracts  for  development  and  production.  The  system  integrator  is  responsible  for 
delivery  of  the  desired  capability,  but  the  government  is  ultimately  responsible  for  it.  Initially, 
there  were  two  main  contracts,  one  to  Digital  System  Resources  Inc.  (DSR)  to  develop  the 
initial  system  and  one  to  Lockheed  Martin  to  integrate  the  system  with  the  existing  platform. 
There  are  currently  four  contracts:  two  contracts  for  engineering  services  and  hardware,  one 
for  integration,  and  one  for  software.  None  of  these  contracts  are  multiple  award  contracts.  The 
program  used  a  combination  of  incentive-fee  and  award-fee  contracts  in  an  effort  to  get  the 
greatest  cooperation  among  all  contractors. 

CSRR  is  a  Navy  program  to  consolidate  and  update  the  radio  room  on  board  subma¬ 
rines.  Initially,  the  system  design,  engineering  and  integration  functions  were  performed  by 
a  prime  contractor,  EB.  EB  subcontracted  with  Lockheed  Martin  for  design  support,  engi¬ 
neering,  and  integration.  Following  initial  installations,  the  government  performed  all  system 
design,  engineering  and  integration,  and  support  and  installation  tasks.  The  NUWC  and  the 
SSC-Charleston  have  since  provided  all  in-service  support  for  CSRR,  except  where  Lockheed 
Martin  has  a  contract  to  provide  support  for  the  software.  The  System  Centers  did  not  partici¬ 
pate  greatly  in  the  design  or  production  of  the  systems.  Rather,  they  had  to  develop  knowledge 
and  expertise  of  the  systems  necessary  to  repair  and  upgrade  equipment. 

While  each  program  pursued  a  unique  contracting  strategy,  there  are  some  common 
themes  regarding  task  responsibility.  Production  has  typically  been  a  contractor  activity.  System 
design,  engineering,  and  integration  have  been  predominantly  contractor  activities  with  some 
government  participation  in  modernization.  In-service  support  and  installation  has  been  pre¬ 
dominantly  a  government  activity  with  support  from  contractors.  All  these  programs  faced 
challenges  integrating  multiple  software  applications  from  other  organizations. 


Roles  and  Responsibilities 

Government  Activities 

For  inherently  governmental  reasons,  the  government  needs  to  participate  in  specific  technical 
and  managerial  activities.  The  government  must  maintain  management  and  decisionmaking 
responsibilities  and  staff  programs  with  personnel  capable  of  undertaking  these  tasks.  While 
contractors  may  identify  what  is  technically  possible,  the  government  should  maintain  respon¬ 
sibility  for  specifying  requirements  and,  importantly,  testing.  The  government  should  maintain 
responsibility  for  developing  architecture  specifications.  It  should  also  guide  the  integration 
effort  by  clearly  specifying  roles  and  responsibilities  for  various  parties,  developing  an  integra¬ 
tion  plan  or  strategy.  The  government  should  participate  in  the  development  of  and  manage 
standards  and  protocols  required  for  the  integration  effort.  While  contractors  may  propose 
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standards,  the  government  should  have  final  approval  of  them.  This  requires  maintaining  tech¬ 
nical  expertise  within  the  government  program  offices,  even  if  most  programming  work  is 
done  by  contractors.  For  Navy  programs,  this  technical  expertise  came  from  the  Warfare  Cen¬ 
ters  and  SPAWAR. 

In  successful  programs,  the  government  maintained  responsibility  in  the  sustainment 
phase  for  maintaining  and  modernizing  materiel  and  equipment.  At  the  same  time,  contractors 
also  played  some  critical  roles  in  program  maintenance  and  modernization.  In  the  ARCI  and 
CSRR  programs,  for  example,  the  government  in-service  support  and  modernization  is  largely 
performed  by  contractors. 

Our  review  of  these  select  programs  indicates  that  major  program  decisions  for  CANES 
need  to  be  made  by  the  appropriate  government  activity,  not  by  industry.  For  inherently  govern¬ 
mental  functions,  the  government  should  maintain  responsibility  for  requirements,  program 
management,  and  operational  testing.  It  should  maintain  technical  authority,  even  though 
system  engineering,  software  engineering  or  hardware  development  may  be  done  by  contrac¬ 
tors.  The  government  needs  to  have  the  information  and  expertise  required  to  offer  integration 
guidance  and  to  create  an  integration  strategy  that  assigns  roles  and  responsibilities  to  various 
parties.  It  also  needs  information  and  expertise  to  support,  install,  and  determine  the  future 
direction  of  the  program. 

When  the  government  contracts  for  services  and  products,  it  can  still  maintain  respon¬ 
sibility  for  key  program  activities.  A  technically  competent  government  representative  can 
participate  in  Integrated  Product  Teams  to  represent  government  interests  and  to  keep  the 
government  aware  of  the  technical  risks  and  challenges  that  the  program  faces.  Carefully  con¬ 
structed  contracts  can  also  ensure  that  the  government  maintains  responsibility  for  key  pro¬ 
gram  decisions. 

industry  Activities  and  Contracting  Strategies 

While  the  government  has  maintained  oversight  and  management  responsibilities  for  success¬ 
ful  programs,  contractors  have  performed  the  bulk  of  design,  development,  and  production 
work.  Table  4.1  shows  contractor  activities  in  successful  programs,  including  primary  systems- 
engineering  and  integration  execution. 

Each  program  pursued  a  different  acquisition  and  contracting  strategy.  Two  of  the  four 
programs  had  a  single  prime  contractor;  the  other  two  programs  had  a  prime  system  integrator 
with  multiple  contracts  for  different  functions.  Each  program  had  strategies  that  evolved  as  the 
program  matured.  CSRR  transferred  system-engineering  and  program-integration  responsi¬ 
bilities  from  industry  to  government  when  the  program  moved  from  system  design  and  devel¬ 
opment  to  in-service  support  and  modernization.  The  Virginia-cX&ss  NPES  program  was  devel¬ 
oped  for  new  ships  only;  the  other  three  programs  focused  on  retrofitting  existing  forces. 

Assignment  of  Roles  and  Responsibilities  for  CANES 

It  is  clear  that  the  government  needs  to  play  a  significant  role  in  the  CANES  program,  includ¬ 
ing  developing  requirements,  program  management,  technical  direction,  and  technical  author¬ 
ity.  Major  program  decisions  must  be  made  by  the  government.  The  government  must  have 
the  information  and  expertise  needed  for  integration  guidance  and  strategy,  assigning  roles  and 
responsibilities.  The  government  also  needs  to  have  the  information  and  expertise  required  to 
support,  install,  and  determine  the  future  direction  of  the  program. 
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Table  4.1 

Industry  Activities  for  MPS,  ARCI,  Virginia- Class  NPES,  and  CSRR 


Activity 

MPS 

ARCI 

VA  NPES 

CSRR 

System  engineering 
and  integration 

Prime  system 
integrator 

Prime  system 
integrator  (LM) 

EB  prime  with 
subcontract  to  LM 
and  NUWC  CNPT 

Development — 

EB  prime  with 
subcontract  to  LM 
Modernization — 
NUWC/SSC 

System  design 

Multiple  contractors 

Multiple  primes 
with  input  from 
user 

Prime  with 
subcontractors 

Prime  with 
subcontractor 

In-service  support 

Multiple  contractors 

Government/LM 

UNK 

NUWC/SSC 
(supported  by  LM) 

Production 

Multiple  contractors 

Multiple  contractors 

Prime  (EB) 

Prime  (EB) 

Installation 

N/A 

Shipyard 

Prime  (EB) 

Modernization — 
SSC-SD 

Assessing  future 
direction 

Government 

Collaborative 

UNK 

UNK 

Configuration 

management 

Prime  system 
integrator 

UNK 

UNK 

SSC 

NOTES:  Configuration  is  defined  as  tracking  and  managing  which  units  have  which  version  of  the  baseline  and 
which  will  receive  an  update.  N/A  =  not  applicable.  UNK  =  unknown. 


The  CANES  program  could  adopt  any  number  of  assignments  of  responsibilities  for  pro¬ 
gram  tasks  and  be  successful.  Our  assessment  of  program  goals  and  other  program  experiences 
shows  no  reason  why  the  CANES  program  could  not  adopt  a  typical  assignment  of  responsi¬ 
bilities,  with  design,  systems  engineering  and  integration,  and  production  activities  performed 
by  contractors  and  overseen  by  government,  at  least  initially.  Collaboration  between  the  pro¬ 
gram  office,  SPAWAR,  and  industry  could  improve  the  ability  of  each  to  perform  its  function. 
It  could  also  help  the  government,  should  it  wish  to  do  so,  to  develop  the  expertise  required  to 
take  on  system  design,  engineering,  and  integration  roles  in  the  future.  To  be  in  the  best  posi¬ 
tion,  government  organizations,  such  as  SSC,  should  be  active  in  system  design,  engineering, 
and  integration  activities  from  the  start  of  the  program. 


Other  Lessons  Learned 

Several  past  network  implementations — ICAN,  the  Shipboard  Wide  Area  Network  (SWAN), 
Total  Ship  Computing  Environment  (TSCE),  Aviation  Data  and  Management  Control  System 
(ADMACS),  and  Integrated  Voice  Communication  System  (IVCS) — also  offer  a  number  of 
lessons  in  requirements,  documentation,  acquisition  and  contracting,  technical  design,  test 
and  evaluation,  supportability,  and  training.  Some  of  the  lessons  we  draw  from  them  here 
were  consolidated  from  earlier  studies  sponsored  by  PEO  C4I  that  were  conducted  by  RAND 
(Schank  et  ah,  2009).  All  are  relevant  to  future  network  implementations.2 


2  We  provide  additional  information  on  the  LPD-17  SWAN  in  Appendix  D,  on  the  ADMACS  in  Appendix  E,  on  the 
TSCE  in  Appendix  F,  and  on  the  IVCS  in  Appendix  G. 
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Tables  4.2  and  4.3  summarize  two  groups  of  lessons:  common  pitfalls  and  recommended 
actions.  Many  of  these  pitfalls  are  well  understood;  indeed,  the  CANES  program  was  designed 
to  address  some  of  them.  Table  4.3  references  mitigation  strategy  by  problem  number  listed 
in  Table  4.2.  Problems  and  solutions  are  discussed  in  much  greater  detail  in  the  appendixes. 


Table  4.2 

Network  Implementation  Pitfalls 


No. 

Potential  Pitfall 

Area 

PI 

No  independent  (third-party)  cost  estimate 
for  expenditures 

Acquisition  and  contracting 

P2 

Lack  of  sharing  of  proprietary  source  code  between  the 
government  and  private  industry 

Acquisition  and  contracting 

P3 

Lack  of  off-the-shelf  replacements  when  companies  go 
out  of  business 

Acquisition  and  contracting,  supportabil- 
ity,  and  technical  design 

P4 

Lack  of  shipbuilder  network  designs  available  to  the  users 

Documentation 

P5 

Lack  of  technical  manuals 

Documentation 

P6 

Insufficient  level  of  understanding  between  the 
government  and  the  shipbuilder  on  requirements 

Requirements 

P7 

Lack  of  subject-matter  expert  input  (for  each  functional 
area)  to  the  shipbuilder;  requirements  made  at  the  ship 
specification  level,  not  the  department  (navigation, 
engineering,  combat  systems,  air)  level 

Requirements 

P8 

Lack  of  configuration  accounting  or  source  code  for 
software  life-cycle  management  upon  ship  delivery, 
making  it  difficult  for  the  Navy  to  fix  problems 

Supportability,  acquisition,  and 
contracting 

P9 

Quality  of  service  not  considered  when  voice  and  controls 
data  depend  on  the  same  backbone 

Technical  design 

P10 

Poorly  tested  software  and  hardware  modifications; 
upgraded  systems  not  tested  for  adverse  effects  on  other 
shipboard  systems 

Testing  and  evaluation 

P11 

No  systemwide  land-based  testing  of  a  system  prior  to 
onboard  installation 

Testing  and  evaluation 

P12 

Lack  of  shipboard  personnel  with  training  and  technical 
expertise 

Training 

P13 

Lack  of  formal  training 

Training 

P14 

Frequent  human  errors 

Training  and  technical  design 

P15 

Networks  and  applications  that  are  not  up-to-date 

Technical  design,  acquisition,  and 
contracting 

P16 

Excessive  life-cycle  costs  due  to  operations  and  maintenance 
(O&M)  costs 

Acquisition  and  contracting 
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Table  4.3 

Network  Implementation  Mitigations 


Mitigation 

Area  (pitfalls  addressed) 

Create  an  integrated  requirements  document  (for  all  ship  networks)  that 
contains  individual  functional-area  requirements 

Requirements  (P6,  P7) 

Require  the  design  team  to  work  with  the  operational  users  of  the  system  to 
identify  system  functional  and  end-user  requirements  prior  to  design 

Requirements  (P6) 

Write  a  well-defined  concept  of  operations  encompassing  the  entire 
system  and  user  functional  interactions  of  individual  networks,  ship  systems, 
and  other  interfaces 

Requirements  (P6) 

Reduce  manual  inputs  by  allowing  data  to  be  passed  from  system  to 
system  whenever  possible 

Technical  design  (P14) 

Conduct  a  risk  analysis  and  implement  a  management  process  with  full- 
scale  testing  under  dynamic  shipboard  conditions  for  all  new  technology, 
equipment,  architecture,  or  configurations  that  have  never  before  been 
used  on  a  ship 

Testing  and  evaluation  (P10) 

Conduct  a  land-based  test  of  the  system  prior  to  shipboard  installation  or, 
if  that  is  too  costly,  develop  a  virtual  integration  concept  that  involves  all 
system  sites 

Testing  and  evaluation  (P10,  P16) 

Ensure  that  CFE  is  not  designed  and  procured  years  before  installation  to 
avoid  hardware  obsolescence 

Contracting  and  acquisition  (P15) 

Develop  a  life-cycle  software  and  maintenance-control  plan 

Supportability  (P16) 

Establish  a  dedicated  organizational  entity  to  serve  as  life-cycle  manager 
in  a  Navy  organization  with  staffing  components  from  headquarters, 
naval  organizations,  and  private  companies 

Supportability  (P3,  P8,  P16) 

Establish  a  distinct  program  and  system  integration  office  that  is  responsible 
for  management  of  all  CFE  and  GFE  system  hardware,  software  maintenance 
and  control,  systems  integration,  system-level  functional  requirements, 
control  for  services  and  resources,  budget  formulation,  future  technical 
changes,  and  plan  executions 

Acquisition  and  contracting  (P3, 
P8,  PI 6) 

Conduct  several  meetings  one  year  before  system  delivery  to  determine 
whether  requirements  are  feasible  or  need  to  be  modified 

Requirements  (P6) 

Put  C4I  personnel  and  systems  on  board  earlier  in  the  shipbuilding 
process  so  that  the  users  are  properly  acclimated  to  the  network 

Training  and  requirements  (P7, 
P12) 

Provide  more  shipboard  training  or  establish  a  reliable  remote 
management  capability  to  effectively  monitor  the  health  of  the  network 

Training  (P8,  P14) 

Ensure  that  networks  are  not  "ship-unique"  to  allow  for  cost- 
effectiveness  in  schoolhouse  training 

Technical  design,  contracting, 
and  acquisition  (P16) 

When  upgrading  systems,  synchronize  multiple  upgrades  so  that 
adverse  effects  on  other  shipboard  systems  are  realized  earlier 

Supportability  (P8) 

CHAPTER  FIVE 


Important  Issues  for  Any  Contracting  Strategy 


Understanding  the  technical  risks  and  their  effects  is  fundamental  to  determining  the  appro¬ 
priate  contract  strategy,  including  specific  language  that  will  help  establish  responsibilities  of 
the  government  and  contractor^).1  This  study  focuses  on  acquisition  and  contracting,  but  this 
chapter  considers  how  technical  issues  of  CANES  affect  contracting  decisions  and  choices.  In 
particular,  it  identifies  risks  that  can  affect  the  FD  contract.  We  explore  risks  (1)  in  the  current 
vision  of  CANES,  (2)  related  to  how  the  system  development  (SD)  and  LRIP  directly  affect 
FD,  and  (3)  identified  in  previous  attempts  to  implement  similar  systems. 

In  this  chapter,  we  first  observe  the  importance  of  software  when  assessing  the  procure¬ 
ment  of  hardware.  Second,  we  highlight  issues  and  challenges  associated  with  requirements, 
metrics,  configuration  and  control,  and  system  integration.  Third,  we  list  a  number  of  other 
technical  risks.  Finally,  we  summarize  general  conclusions. 


Requirements  and  Specifications 

Importance  of  Getting  the  Initial  Requirements  Right 

Success  or  failure  in  a  project  can  often  be  traced  to  initial  development  of  requirements. 
Specifying  appropriate  detail  in  requirements  is  challenging.  There  is  risk  in  both  overspecihca- 
tion  and  underspecification.  There  is  also  risk  in  allowing  too  many  changes  and  in  being  too 
inflexible  to  change. 

The  Traditional  Approach  and  the  CANES  Approach 

Traditional  DoD  approaches  to  large-system  design  usually  begin  with  the  enumeration  of  all 
requirements  of  a  system  before  proceeding  to  design  and  development.  This  appears  to  be  the 
approach  that  PEO  has  taken  with  CANES.  PEO  C4I  is  also  providing  a  functional  archi¬ 
tecture  that  will  allow  the  SD  contractors  maximum  flexibility  in  design.  The  SD  contractors 
will  develop  a  functional  realization  of  the  architecture,  refined  where  needed,  to  meet  PEO 
requirements.  Ideally,  the  system  will  evolve  through  frequent  updates  to  its  design. 

Flexible  Requirements  are  a  Key  Lesson  Learned 

The  long-troubled  Joint  Tactical  Radio  System  (JTRS)  program  and  ARCI  offer  many  lessons 
for  setting  requirements.  One  of  these  lessons  has  to  do  with  the  ultimate  adverse  impacts  of 


1  Previous  attempts  at  network  consolidation  in  the  Navy  (see  ICAN  program  for  CVNs)  were  hurt  by  poor  risk  mitiga¬ 
tion  early  in  the  program.  This  adversely  affected  development,  testing,  installation  and,  ultimately,  system  performance. 
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inflexible  and  unnecessarily  challenging  requirements.  Initial  requirements  made  the  system 
technically  very  challenging,  which  led  to  a  failure  to  meet  initial  requirements,  increasing  cost 
and  creating  delay.2 

One  reason  that  the  ARCI  program  has  succeeded  is  because  it  specifies  and  then  meets 
small  increments  of  capability.  Although  the  CANES  program  will  be  much  broader  than 
ARCI,  it,  too,  would  benefit  from  specifying  and  then  meeting  minimum  increments  to  satisfy 
the  most  fundamental  requirements.  The  program  would  also  benefit  from  giving  system  and 
application  developers  the  greatest  flexibility  possible. 

Observations  and  Examples  from  Existing  CANES  Specifications 

CANES  architectural  (and  subsequent)  specifications  have  very  good  traceability,  but  they  lack 
references  for  specific  performance  metrics.  Some  reference  to  operational  conditions  or  the 
Initial  Capability  Document  can  help  achieve  verification  and  acceptance  from  users.  Table  5.1 
provides  examples  of  two  requirements  and  the  issues  they  raise. 

For  the  second  example  in  Table  5.1,  it  would  seem  more  prudent  to  separate  performance 
requirements  such  as  “less  than  1  second”  from  the  specification.  The  requirement  is  that 
CANES  shall  federate  all  near-real-time  services.  A  more  precise  performance  requirement  can 
be  defined  during  system  acceptance  testing. 

Prioritize  Vital  over  Desirable  Requirements 

System  specification  should  prioritize  vital  over  desirable  but  possibly  costly  requirements.  If  it 
is  not  possible  to  do  this  until  after  the  contract  award,  the  Navy  should  be  prepared  to  change 
requirements  as  necessary  over  the  course  of  the  contract.3 


Table  5.1 

Examples  of  Requirements 


Requirement 

Reference 

Comment 

"Large  Screen  Display  resolution  shall 
support,  at  a  minimum,  1080p." 

UID03163  in  CANES  Program 
Office,  Architecture 
Specification,  2009. 

This  specific  example  will  likely  not 
cause  much  consternation  for  devel¬ 
opers,  but  it  shows  a  requirement 
written  to  the  best  commercially  avail¬ 
able  standard,  rather  than  the  mini¬ 
mum  capability  required. 

"The  CANES  System  shall  provide  lim¬ 
ited  federation  with  NCES  discovery  of 
people  and  services  (Threshold).  The 
CANES  system  shall  provide  federation 
of  all  near-real-time  services  (Objec¬ 
tive).  Near-real-time  =  less  than  1  second 
with  a  relative  variance  of  0.5  seconds 
squared." 

UID00581  in  CANES  Program 
Office,  Architecture 
Specification,  2009. 

This  requirement  depends  on  systems 
outside  CANES,  and  yet  the  require¬ 
ment  seems  fairly  stringent  for  any 
potential  developer  to  meet.  It  lets 
the  developer  define  "limited," 
making  this  an  example  where  a  mini¬ 
mum  amount  of  capability  could  be 
delivered  and  anything  beyond  that 
could  be  costly  for  the  Navy. 

2  The  need  for  flexible  requirements  is  also  espoused  in  National  Research  Council  (2010). 

3  National  Research  Council  (2010)  describes  a  process  of  identifying  “Big  R”  and  “Small  R”  requirements,  where 
“Big  R”  requirements  are  the  higher-priority,  expected  outcomes  and  “Small  R”  requirements  are  more  detailed  require¬ 
ments  that  are  expected  to  evolve. 
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Too  many  noncritical  requirements  will  strain  system  developers.  It  is  important  to  iden¬ 
tify  the  most  important  requirements  so  that  those  of  lesser  importance  can  be  relaxed  or 
delayed  in  order  to  meet  more  important  requirements  and  program  schedule. 

Programs  can  manage  a  large  number  of  requirements  if  the  requirements  are  prioritized 
adequately.  The  current  architecture  and  functional  specifications  do  not  make  clear  what 
should  be  the  minimum  level  of  specification  for  CANES  functionality.  Although  an  absolute 
prioritization  may  not  be  immediately  apparent,  it  is  vital  to  analyze  requirements  and  deter¬ 
mine  which  are  truly  required  and  which  are  desirable  but  not  required. 

The  requirements  for  CANES  were  developed  and  consolidated  from  the  requirements 
documents  of  legacy  programs,  which  were  designed  to  operate  independently  of  one  another. 
The  PEO  should  reconsider  requirements  for  operation  with  an  open  architecture. 


Measures  and  Metrics 

Operational  Availability 

Requirements  and  specifications  are  only  as  good  as  the  measures  and  metrics  used  to  make 
them.  Porche  et  al.  (2010),  in  a  2009  study  sponsored  by  2009  PEO  C4I,  identified  certain 
measures  used  for  specifying  network  performance  in  requirements  documents  that  were  out¬ 
dated  and  too  general.  For  example,  operational  availability  (Ao)  was  originally  conceived  as 
an  accounting  measure  for  machines  and  other  hardware.  The  concept  of  being  “up  or  down” 
is  clear  for  a  mechanical  device.  For  networks,  this  metric  is  insufficient,  because  networks  can 
be  both.4 

User  Perception  of  Availability 

A  network  can  be  operating  in  a  degraded  mode  that  may  be  satisfactory  but  prevent  some 
users  from  performing  a  specific  task.  In  such  cases,  the  network  may  be  technically  “up,”  but, 
as  perceived  by  select  users  in  the  fleet,  it  is  down.  Both  PEO  C4I  staff  and  trouble  tickets  from 
the  Navy’s  Remedy  database  indicate  this  has  been  a  problem  in  the  past.5 


Configuration  Control 

Software  configuration  control  will  take  on  a  new  meaning  for  the  PEO.  Instead  of  allowing  a 
large  number  of  heterogeneous  configurations,  the  PEO  will  try  to  consolidate  and  manage  a 
reduced  number  based  on  a  consistent  architecture. 

The  ongoing  need  for  multiple  software  configurations  is  due  to  the  nature  of  naval  opera¬ 
tions,  the  array  of  platform  types,  and  ship  availability.  Despite  a  consistent  architecture,  the 
CANES  program  still  must  manage  many  different  baselines  because  each  ship  class  may  have 


4  The  CANES  Architecture  specification  states  that  “a  service  is  considered  down  when  it  is  unavailable  or  inaccessible  by 
user  access  devices  within  a  given  platform  and  enclave”  (CANES  Program  Office,  Architecture  Specification  1.4.2,  2010). 
This  statement  does  not  translate  well  to  software  in  general,  nor  to  a  service-oriented  approach  to  software  specifically.  This 
type  of  software  service  availability  is  not  captured  by  the  availability  Key  Performance  Parameter. 

5  Remedy  is  a  software  application  produced  by  BMC  Software,  Inc.  It  is  one  of  the  most  widely  distributed  tracking  sys¬ 
tems  for  business  processes.  In  the  case  of  the  Navy  (and  also  at  RAND),  Remedy  is  used  to  track  IT-related  problems  or 
issues  reported  by  users  in  the  field.  Trouble  ticket  refers  to  an  instance  of  such  a  report. 
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a  different  implementation  of  the  architecture.  As  we  will  discuss  later,  representatives  from 
other  programs  (such  as  the  Air  Force’s  Mission  Planning  Enterprise)  frequently  cited  software- 
configuration  management  as  a  major  challenge. 

As  it  stands  today,  software  configuration  control  is  a  part  of  the  application  integration 
(AI)  process.  Its  role  should  perhaps  be  elevated  to  a  higher  level  of  governance.  Using  configu¬ 
ration  control  to  manage  baselines  can  help  reduce  AI  complexity.  This  will  be  critically  impor¬ 
tant  to  the  success  of  CANES.  The  ability  of  applications  to  manage  many  baselines  is  likely 
proportional  to  how  well  the  applications’  architecture  design  or  data  flows  can  be  modified.6 


System  Integration 

An  ongoing  future  challenge,  and  perhaps  the  most  important  technical  risk  for  CANES,  is 
how  to  continuously  integrate  new  applications  quickly  and  successfully. 

Like  ICAN,  SWAN,  and  TSCE,7  the  CANES  program  seeks  a  consolidation  and 
integration  of  a  certain  number  of  onboard  networks.  Specifically,  it  consolidates  ISNS, 
CENTRIXS-M,  IC,  SCI,  SVDS,  and  SubLAN,  to  include  Total  Ship  and  VIXS  (CANES 
Program  Office,  2008b).  It  differs  from  some  previous  efforts  (like  ICAN)  in  not  having  to 
integrate  ship  control  and  weapons-system  networks. 

A  large  element  of  system  integration  is  the  test-and-evaluation  period  of  software  and 
hardware  products.  The  validation  and  verification  (V&V)  of  applications  will  determine  their 
readiness  to  be  a  part  of  a  future  CANES  baseline.  The  AI  team  must  consider  the  specific 
needs  of  an  open  architecture.  Application  developers  and  CANES  developers  need  to  collabo¬ 
rate  through  the  AI  team  to  evaluate  how  well  their  software  will  work  together.  This  is  com¬ 
plicated  by  the  need  of  the  CANES  program  to  consider  many  other  applications.  Application 
developers,  CANES  developers,  and  the  AI  team  may  affect  each  other  in  ways  not  foreseen, 
requiring  them  to  find  ways  to  mitigate  undesirable  effects. 

Integration-verification  tests  will  come  from  the  application  developers.  The  CANES 
program  is  responsible  for  ensuring  that  CANES  runs.  The  application  providers  are  respon¬ 
sible  for  ensuring  that  their  applications  run  on  CANES.  This  presents  some  risk  if  key  devel¬ 
opment  specifications  are  not  shared  among  AI,  CANES,  and  application  developers,  ensuring 
that  the  integrated  system  functions  robustly.  One  way  to  mitigate  this  risk  is  early  adoption 
of  frequent  integration  testing  by  a  contractor  or  independent  government  agency.  Stage  4  of 
the  Application  Integration  Process  and  Service  Framework  addresses  this  (Program  Executive 
Office,  C4,  2009).  Programs  should  also  make  clear  who  will  write  and  conduct  the  tests.  If 
the  contractor  writes  the  integration  tests,  then  the  FD  contract  needs  to  make  clear  that  the 


6  Adaptive  management  can  help  to  improve  configuration  management.  It  is  a  process  to  deal  with  the  uncertainty  and 
other  challenges  posed  by  evolving  designs. 

7  Total  Ship  Computing  Environment  describes  a  Raytheon  approach  for  networks  and  IT  on  the  Zumwalt  class.  The  term 
may  have  originally  been  coined  by  PEO  C4I  to  describe  the  shipboard  architecture,  integration,  and  technical  approach 
for  implementing  a  consolidated,  common  network,  processing  and  data-sharing  solution  for  a  ship.  The  terms  TSCE-I 
or  TSCE/I  or  TSCI  refer  to  the  installed  fiber  optics,  copper  cabling,  hardware  and  software,  and  ship  support  systems 
interface  (power,  air  conditioning,  etc.)  on  a  ship.  A  TSCE/I  contract  was  awarded  to  Raytheon,  and  the  term  seems  more 
synonymous  with  its  particular  implementation  on  the  DDG-100.  Raytheon  defines  TSCE-I  as  “an  integrated  suite  of 
standardized  OA  [open-architecture]  hardware,  operating  system,  middleware  and  infrastructure  services”  which  “forms 
the  backbone”  of  the  TSCE  for  all  DDG-1000  software  application  programs  (Raytheon,  2006). 
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integration  testers  can  either  accept  or  refuse  a  test  as  valid.  Performance  testing  should  be  dis¬ 
tinct  from  functional-verification  testing  and  focus  on  meeting  “minimum  amount  of  service” 
(threshold).  For  example,  a  functional  test  might  be  determining  whether  the  system  turns 
on  (yes  or  no),  and  the  performance  test  would  be  a  measure  of  how  long  it  takes  to  turn  the 
system  on  (a  numerical  assessment).  While  it  is  sometimes  hard  to  separate  performance  test¬ 
ing  from  functional  testing,  it  is  worthwhile  to  do  so  where  possible.  It  is  better  for  the  PEO  to 
have  a  contractor  first  prove  functionality,  then  to  test  performance.  Current  plans  are  for  the 
Navy’s  SSC  to  handle  integration  testing. 

COTS 

One  of  the  objectives  of  CANES  is  to  use  COTS  software  and  hardware  where  available  and 
applicable.8  This  is  a  valuable  lesson  learned  from  many  programs,  including  ARCI  and  the 
Automatic  Identification  System.  The  CANES  Program  Office,  2008a,  notes  that  “CANES 
relies  heavily  on  COTS  components.”  Specifically,  the  requirements  (see  UID00386)  say 
“CANES  shall  use  commercial  off-the-shelf  (COTS)  products,  wherever  possible  (Objective).” 
The  statement  “wherever  possible”  is  a  good  example  of  a  capability  specified  in  the  require¬ 
ments  language  in  a  manner  open  to  varying  interpretation.9 

Supportability 

Supportability  issues  should  concern  the  CANES  program  (or  any  program).  Many  ICAN 
problems  stemmed  from  poor  training,  lack  of  technical  manuals,  and  poor  testing  and  evalua¬ 
tion  for  software  and  hardware  (see  Appendix  B  for  a  more  detailed  discussion).  Supportability 
must  be  addressed  in  the  design10  and  contracting  considerations  for  a  system.  Intuitive  inter¬ 
faces,  global  management  software  (KSA  7),  and  online  manuals  managed  by  a  third  party  can 
all  help  improve  supportability. 

Crew  rotation  will  also  greatly  affect  network  maintenance  (and  hence  will  require  reli¬ 
ance  on  a  stable  base  of  maintenance  providers  elsewhere).11  CANES  should  help  address  some 
of  these  issues  if  it  provides  (as  desired  and  once  fully  deployed)  a  consistent  architecture  across 
platforms,  despite  the  many  baselines  to  be  managed. 

Within  CANES,  there  are  vestiges  of  traditional  engineering  methods  employed  by 
DoD,  mixed  with  more-modern  approaches  toward  systems  engineering.  Classic  approaches 
to  development  that  involve  well-defined  specifications  can  be  dangerous  to  systems  that  evolve 
quickly.  They  are  also  antithetical  to  modern  evolutionary  approaches  to  design.  Less  rigid  evo¬ 
lutionary  ecosystem  methods — for  example,  those  used  by  major  companies  such  as  Apple  and 
Google — may  be  better  for  large  systems  because  they  provide  the  most  flexibility  (Denning, 
Gunderson,  and  Hayes-Roth,  2008).  These  methods  expose  the  system  to  risk  in  such  a  way 
that  subsequent  failures  can  be  used  to  make  the  system  more  robust.  The  design  needs  to  be 


8  The  challenges  associated  with  the  Department  of  Defense  using  COTS  have  been  widely  discussed.  Burbank  and  Kasch 
(2004)  provide  an  overview  of  several  common  issues,  including  robustness  to  interference  (both  intentional  and  uninten¬ 
tional),  covertness,  security,  scalability,  and  support  for  end-to-end  quality-of-service  (QoS). 

9  A  suggestion  for  the  FD  contract  is  to  either  provides  incentives  for  use  of  COTS  equipment  or  require  program  approval 
for  non-COTS  equipment. 

10  The  effect  of  complexity  on  support  can  also  affect  development  and  design  issues.  The  DDG-1000  network  (e.g.,  TSCE) 
has  at  least  7  million  lines  of  code.  Supportability  will  be  a  challenge  for  such  complexity. 

11  This  is  particularly  necessary  when  dealing  with  the  encryption  devices. 
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open  to  change  for  these  methods  to  work;  such  openness  to  modification  should  be  specified 
in  the  FD  contract. 


Other  Technical  Risk  Areas 

There  are  many  technical  risks,  not  all  of  which  can  be  neatly  characterized.  We  discuss  these 
below. 

Inherent  Risks  with  Server  Virtualization 

Server  virtualization  is  an  increasingly  common  approach  in  industry.  The  CANES  program 
is  also  undertaking  it  so  as  to  make  the  most  efficient  use  of  hardware  (servers).  Server  virtu¬ 
alization  allows  for  multiple  servers  in  one  box  (Miller,  2007).  Virtualization  allows  multiple 
operating  systems  on  an  individual  server.  It  allows  multiple  applications  to  share  comput¬ 
ing  resources.  Virtualization  allows  blade  servers  to  further  reduce  space,  weight,  and  power 
requirements,  and  for  rapid  reconfiguration  and  computing  capacity  (Miller,  2007).  Virtual¬ 
ization  is  a  fundamental  characteristic  of  the  CCE. 

That  does  not  mean  it  is  risk-free.  Among  concerns  about  virtualization  are  those  regard¬ 
ing  information  assurance.  Gartner,  Inc.  (2006)  says  that  “60  percent  of  virtualized  servers  will 
be  less  secure  than  the  physical  servers  they  replace  through  2012.” 

Another  concern  is  “over-virtualizing”  a  server.  This  may  occur  if  a  central  processing  unit 
is  overtaxed  or  has  insufficient  storage. 

Upgradability 

C4I  programs  require  annual  upgrading.12  Early  planning  considerations  must  consider  flex¬ 
ibility  for  accommodating  future  needs.  Approaches  suggested  by  industry  experts  are  to 
(1)  use  modular  equipment,  (2)  rely  on  flexible  infrastructure,  and  (3)  pursue  centralized  man¬ 
agement.  In  addition,  a  new  platform  should  (4)  forecast  a  design  envelope  for  network  and 
networked  systems.  (For  further  discussion,  see  Schank  et  ah,  2009).  This  “envelope”  should 
specify  power;  heating,  ventilation,  air  conditioning  (FIVAC);  and  the  physical  space  boundar¬ 
ies  of  the  network. 

Some  needs,  such  as  information  assurance  and  cybersecurity,  will  be  difficult  to  antici¬ 
pate.  These  are  particularly  tough  to  plan  because  threats  constantly  change.  It  is  difficult  to 
anticipate  future  types  of  attacks.  Furthermore,  new  threats  will  require  quick  and  efficient 
installation  of  new  security  precautions.  A  flexible  infrastructure  is  a  requirement  as  well  as  a 
means  to  insert  the  updates  through  the  fleet  quickly. 

Inherent  Risk  in  Maintaining  and  Supporting  CFE 

Navy  personnel  have  indicated  that  PEO  C4I  has  had  challenges  with  unique  CFE.  In  particu¬ 
lar,  Raytheon’s  SWAN  for  the  LPD-17  and  Newport  News’  ICAN  implementation  for  carriers 


12  Obsolescence  was  a  major  problem  in  previous  network  consolidation  attempts.  Schank  et  al.  (2009)  discuss  the  problem 
of  continual  technology  upgrades  (e.g.,  C4I).  The  CANES  program  is  adopting  an  annual  or  biennial  cycle  for  upgrading 
software  and  a  quadrennial  cycle  for  upgrading  hardware.  This  approach  has  both  benefits  and  drawbacks.  One  benefit  is 
that  it  mitigates  technical  obsolescence.  One  drawback  is  the  subsequent  increased  likelihood  of  requirements  growth.  This 
could  be  difficult  to  accommodate  if  growth  margins  were  not  planned. 
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were  initially  difficult  to  support  and  maintain  (see  Appendix  B  for  a  more  detailed  discussion). 
Network  implementations  for  the  two  most  recent  littoral  combat  ship  platforms  have  also 
drawn  criticism  for  problems  with  CFE. 

Many  of  these  CFE  systems  have  limited  integration,  usability,  and  transparency  in  the 
technical  aspects  required  to  maintain  the  systems.  This  causes  PEO  to  spend  funds  address¬ 
ing  issues  that  should  have  been  addressed  by  the  developer.  The  upgradeability  of  the  small- 
production,  unique  system  can  be  difficult  and  costly  for  PEO  C4I  if  there  is  a  lack  of  transpar¬ 
ency  in  the  architecture  and  thus  difficulty  in  future  integration  efforts. 

Providing  Adequate  Technical  Training 

Training  for  users  and  network  operators  remains  vital  for  reliable  network  operation.  More 
training  and  IT  personnel  will  decrease  network  trouble  calls.  Porche  et  al.  (2010)  found  that 
human-related  trouble  tickets  accounted  for  most  trouble  tickets  generated  for  ISNS  on  ten  air¬ 
craft  carriers  between  2006  and  2008  and  that  increasing  each  carrier’s  IT  staff  would  reduce 
the  total  number  of  human  errors. 


Observations,  Conclusions,  and  Recommendations 

CANES  is  prompting  rethinking  of  how  the  Navy  procures  software  and  hardware  for  its 
afloat  platforms.  Its  success  will  depend  on  its  flexibility  for  change,  which  will  be  bolstered  by 
its  software  and  hardware  update  cycles. 

Quality  in  the  SD  Phase  Will  Drive  FD  Quality 

A  quality  design  coming  out  of  the  SD  phase  will  define  the  constraints  placed  on  the  applica¬ 
tion  programs  in  FD. 

Plan  Early  to  Mitigate  Technology  Risks 

PEO  C4I  should  consider  a  plan  to  mitigate  the  risk  of  an  incomplete  or  inadequate  design  in 
the  SD  phase  or  difficulty  proving  CANES  reliability  in  LRIP.  A  “crawl,  walk,  run”  approach 
that  targets  the  most  important  requirements  first  could  keep  the  program  on  schedule  in  key 
areas.  The  program  should  start  with  core  aspects  and  then  let  other  aspects  evolve  as  needed. 

Prioritize  Vital  Requirements 

Identifying  the  most  vital  requirements  will  ultimately  promote  success.  This  will  give  the 
program  more  flexibility  to  throw  out  less  vital  requirements  that  become  problematic  for  or 
unwanted  by  users.  This  agile  approach  will  require  careful  management  as  well  as  creative 
contracting  options. 

Ensure  FD  Contract  Flexibility 

To  retain  functional  baselines  through  upgrade  cycles,  system  requirements  may  have  to 
change  based  on  feedback  from  the  fleet  and  changes  in  the  “state-of-the-shelf”  hardware 
and  software.  The  FD  contracts)  must  be  flexible  enough  to  handle  the  baseline  configura¬ 
tions  of  the  configuration  management  team.  The  need  to  manage  CANES  and  non-CANES 
baselines  simultaneously  further  complicates  configuration  management,  as  do  periodic 
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software  upgrades  from  multiple  offices.  This  means  that  CANES  managers  will  need 
contracting  flexibility.  The  contract  should  address  potential  dependencies  or  constraints  of 
maintaining  multiple  baselines. 


CHAPTER  SIX 

Conclusions  and  Recommendations 


Consolidating  older  C4I  applications  under  the  CANES  umbrella  will  be  challenging.  It  will 
require  development  of  virtualization  software  that  allows  multiple  applications  to  run  on  a 
single  server.  Once  CANES  is  initially  deployed  to  the  fleet  (itself  a  major  task),  the  CANES 
program  office  will  have  to  constantly  work  with  other  program  offices  within  and  outside  of 
the  PEO  C4I  structure  to  receive  timely  and  workable  upgrades  to  new  applications.  As  the 
CCE  is  updated,  program  managers  will  need  to  ensure  that  all  the  applications  running  on  the 
system  are  compatible.  Integrating  the  inputs  from  multiple  stakeholders  will  be  challenging. 

The  CANES  program  acquisition  strategy  is  unique.  The  CCE  (which  entails  develop¬ 
ment  of  the  computing  architecture,  including  the  selection  of  specific  hardware  and  the  devel¬ 
opment  of  virtualization  software)  will  be  acquired  through  a  competitive  contract.  A  down- 
select  will  occur  for  full-rate  production.  Although  the  selected  design  is  expected  to  support 
current  applications  and  services,  application  owners  will  be  responsible  for  developing  future 
applications  that  are  consistent  with  the  CANES  architecture.  When  the  program  enters  the 
FD  phase,  it  will  hold  another  competition.  At  this  point,  software  upgrades  will  occur  on 
a  one-  to  two-year  cycle,  and  hardware  upgrades  will  occur  on  a  four  year-cycle.  The  SSC- 
Charleston  will  be  responsible  for  loading  the  new  applications  onto  the  CCE. 


Programs  Analyzed 

We  reviewed  several  programs  that  share  important  characteristics  with  CANES,  including 
complex  integration  challenges  and  an  open  architecture  approach  to  system  development. 
Other  similarities  between  these  programs  and  CANES  include  requiring  the  integration  of 
hardware  and  software  from  different  stakeholders  (sometimes  with  competing  objectives)  and 
with  disparate  applications,  operating  software,  and  servers. 

Although  the  programs  represented  a  variety  of  life-cycle  phases,  Acquisition  Categories 
(ACAT),  and  levels  of  funding,  they  offer  useful  insights  for  the  CANES  program.  Each  pro¬ 
gram  pursued  a  unique  contracting  strategy,  but  we  identified  some  common  themes  regarding 
program  responsibilities.  For  example,  production  was  typically  a  contractor  activity.  System 
design,  engineering,  and  integration  were  also  predominantly  contractor  activities  but  involved 
some  government  activity  during  modernization  or  in-service  support.  In-service  support  and 
installation  were  predominantly  government  activities,  with  support  provided  by  contractors. 

Another  theme  common  to  successful  programs  is  strong  government  leadership.  Gov¬ 
ernment  representatives  have  participated  in  specific  technical  and  managerial  activities  of 
successful  programs.  Perhaps  most  important,  the  government  has  maintained  program  man- 
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agement  and  decisionmaking  responsibilities.  While  contractors  may  have  identified  what  is 
technically  possible  and  done  most  of  the  actual  software  and  hardware  development,  the 
government  maintained  responsibility  for  specifying  the  requirements  and,  importantly,  test¬ 
ing.  The  government  maintained  responsibility  for  developing  the  architecture  specification.  It 
also  guided  the  integration  effort  by  clearly  specifying,  through  an  integration  plan  and  strat¬ 
egy,  roles  and  responsibilities  for  various  parties.  This  included  government  participation  and 
management  of  standards  and  protocols  necessary  for  the  integration  effort.  While  contractors 
may  have  proposed  standards,  the  government  had  ultimate  approval  over  them.  This  required 
maintaining  technical  expertise  within  the  government  program  offices.  For  Navy  programs, 
this  technical  expertise  came  from  the  Warfare  Centers  and  SPAWAR. 

As  successful  programs  moved  into  the  sustainment  phase,  the  government  retained 
responsibility  for  maintaining  and  modernizing  materiel  and  equipment.  Contractors  did  have 
some  critical  roles  in  maintenance  and  modernization  for  these  programs.  In  the  ARCI  and 
CSRR  programs,  for  example,  the  government  in-service  support  and  modernization  is  largely 
performed  by  contractors. 


Contract  Strategy  for  CANES 

There  is  no  single  “right”  acquisition  or  contracting  strategy  for  the  CANES  program  in  FD. 
Both  the  single  prime  contract  model  and  allocation  of  tasks  to  different  government  and 
contractor  organizations  can  be  successful  approaches  for  CANES,  if  properly  managed  and 
executed.  Each  alternative  has  unique  pros  and  cons. 

Nevertheless,  our  research  indicates  that  a  good  approach  for  the  CANES  program  would 
be  to  split  it  into  three  main  functions  and  assign  each  function  to  the  provider  offering  the 
best  value  as  defined  by  quality  and  cost.  The  three  main  functions  are  (1)  a  technical  func¬ 
tion,  consisting  of  technical  advice  and  engineering  services  (including  configuration  manage¬ 
ment  and  system  integration);  (2)  a  production  function  to  procure  and  assemble  the  systems; 
and  (3)  an  installation  function.  Our  analysis  indicates  that  this  approach  would  best  enable 
the  CANES  program  to  achieve  a  competitive  acquisition  strategy.  This  strategy  would  mini¬ 
mize  technical  and  programmatic  risks  by  assigning  performance  of  technical,  production,  and 
installation  functions  to  organizations  providing  the  best  value.  It  would  allow  for  the  techni¬ 
cal  flexibility  required  and  support  an  aggressive  schedule.  The  preferred  model  would  have 
schedule  incentives  as  well  as  the  flexibility  required  for  constant  technical  updates,  uncertain¬ 
ties  associated  with  an  ever-changing  ship-availability  schedule,  and  unexpected  integration 
challenges. 

Our  contract  Model  A  would,  we  submit,  best  enable  the  CANES  program  to  achieve 
these  outcomes.  It  would  use  different  contracts  for  different  functions.  One  contract  would 
provide  the  necessary  technical  and  engineering  effort,  including  design  and  integration.  This 
contract  could  be  competitively  awarded  but  should  cover  a  number  of  fiscal  years  to  ensure 
continuity  and  avoid  costs  and  disruption  associated  with  contractor  turnover.  The  FD  produc¬ 
tion  effort  in  this  model  would  be  carried  out  by  contractors  receiving  periodic  and  competi¬ 
tive  MAC  IDIQ  awards.  SPAWAR’s  IMO  would  manage  installation  and  interactions  with 
other  activities,  using  Alteration  Installation  Team  (AIT)  multiple  award  contractors  with 
experience  in  shipyard-work  processes. 
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The  preferred  strategy,  Model  A,  is  superior  to  the  Single  Prime  Contractor  option  in 
several  ways. 

•  It  requires  active  and  continuous  government  involvement,  which,  as  noted  earlier,  is 
common  among  successful  military  IT  programs. 

•  It  obtains  frequent  competitive  prices  for  IT  hardware  in  an  environment  where  hardware 
capabilities  and  prices  are  constantly  improving. 

•  It  uses  proven  SPAWAR  IMO  processes  to  install  the  CANES  systems  onboard  warships 
and  does  not  require  the  development  of  new  processes  and  the  negotiation  of  numerous 
contract  changes  to  reflect  constantly  changing  ship  schedules  and  shipyard-service  costs. 

Because  it  would  use  the  IMO  for  CANES  installation,  Model  A  is  superior  to  Models  B 
and  C,  which,  like  the  Single  Prime  Contractor  option,  would  require  the  development  of  new 
processes  and  the  negotiation  of  numerous  contract  changes.  Model  A  is  also  preferable  to  the 
Government  option  because  it  obtains  competitive  prices  for  IT  hardware. 


Important  Considerations  for  Any  Contract  Strategy 

Assessments  of  the  CANES  program  and  other,  similar  programs  indicate  that  there  are  three 
areas  in  FD  on  which  the  program  office  should  focus.  They  are  the  integration  of  the  initial 
system  and  future  upgrades,  the  development  and  specification  of  requirements,  and  configu¬ 
ration  management. 

An  ongoing  future  challenge,  and  perhaps  the  most  important  technical  risk  for  CANES, 
is  how  to  quickly  and  successfully  integrate  new  applications.  A  significant  component  of 
system  integration  is  the  testing.  The  testing  and  evaluation  requirements  for  CANES  verifi¬ 
cation  are  derived  from  the  PEO’s  requirements,  and  the  integration  verification  tests  are  to 
come  from  the  application  developers.  The  sharing  of  responsibility  among  AI,  CANES,  and 
application  developers  for  ensuring  that  the  integrated  system  functions  robustly  has  inher¬ 
ent  risk.  With  shared  responsibility,  it  is  unclear  how  problems  will  be  resolved.  One  way  to 
mitigate  this  risk  is  to  adopt  early  and  frequent  integration  testing  by  an  independent  govern¬ 
ment  agency  or  contractor.  Whatever  approach  is  adopted,  it  must  be  clear  who  will  write  and 
conduct  tests. 

Network-integration  efforts  also  require  careful  specification  of  requirements  in  order  to 
achieve  successful,  open,  service- oriented  systems.  Finding  the  right  level  of  detail  to  provide 
to  contractors  is  challenging.  The  CANES  program  has  provided  an  architecture  that  allows 
SD  contractors  to  define  how  CANES  system  requirements  are  met.  This  gives  the  contractor 
a  greater  level  of  flexibility  but  could  be  constrained  by  requirements  that  are  too  specific  or 
which  may  only  be  achieved  singly.  Having  a  requirements  prioritization  process  in  place  that 
will  allow  for  negotiation  of  requirements  will  not  only  help  the  program  to  achieve  its  goals 
but  is  also  consistent  with  current  Office  of  the  Secretary  of  Defense  guidance  (OSD,  2008). 

Instead  of  allowing  a  large  number  of  heterogeneous  configurations,  the  PEO  will  try  to 
consolidate  and  manage  a  reduced  number  of  configurations  based  on  a  consistent  architec¬ 
ture.  This  will  minimize  risk  to  application  developers. 

Our  research  suggests  that  the  following  six  activities  can  help  the  program  office  miti¬ 
gate  risks  related  to  integration,  requirements,  and  configuration  management. 
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•  Make  software  and  hardware  configuration  control  a  priority. 

•  Adopt  an  “early  and  often”  approach  to  integration  and  testing  that  will  be  performed  by 
an  independent  government  entity,  contractor,  or  the  CANES  technical  authority. 

•  Establish  a  development  and  integration  process  that  allows  for  more-flexible  requirements. 

•  Adopt  a  development  process  that  tolerates  problems  and  failures  in  select  areas  that  can 
then  be  used  to  develop  a  more-robust  system. 

•  Carefully  select  measures  and  metrics  of  system  performance  so  that  meaningful  assess¬ 
ments  of  CANES  can  be  made. 

•  Prioritize  requirements  and  then  adopt  a  “crawl,  walk,  run”  approach  in  which  capability 
is  obtained  incrementally. 


APPENDIX  A 


Case  Study:  Mission  Planning  System 


The  Air  Force’s  Mission  Planning  System  (MPS)  program  started  in  2002.  It  is  intended  to 
facilitate  pre-  and  post-mission  planning  by  most  types  of  Air  Force  (and  some  other  Service) 
aircraft.  This  is  a  large,  ACAT-1  D  program  that  affects  the  entire  Air  Force  aircraft  inventory. 
The  MPS  consists  of  a  variety  of  software  modules  that  run  on  COTS  hardware  (personal 
computers).  Software  modules  include 

•  weather  data 

•  aircraft  route  planning 

•  intelligence  data 

•  refueling 

•  electronic  warfare  planning 

•  threat  updates 

•  target  area  planning 

•  mission  rehearsal 

•  air  tasking  order  information. 

The  MPS  moves  legacy  UNIX  and  PC-based  systems  and  capabilities  onto  a  single,  mod¬ 
ular,  open- architecture  system  that  can  run  on  commercial  laptops.  Mission  planning  is  done 
before  aircraft  start  the  mission.  MPS  data  are  then  inputted  to  the  aircraft  and  available  to 
ground  personnel  who  support,  monitor,  and  analyze  the  air  mission. 

The  MPS  software  architecture  has  three  elements:  (1)  a  framework  used  by  all  aircraft 
types,  (2)  functionality  required  by  subsets  of  aircraft,  such  as  fighters  and  bombers  and  pro¬ 
vided  through  a  common  component,  and  (3)  functionality  unique  to  specific  aircraft  and 
provided  through  the  Unique  Planning  Component  (UPC).  The  software  provided  across  the 
Air  Force  by  the  MPS  Program  Office  (at  Hanscom  Air  Force  Base,  Massachusetts)  integrates 
these  three  components  for  different  types  of  aircraft. 

The  MPS  project  manager  (PM)  has  the  considerable  challenge  of  integrating  software 
provided  by  aircraft  PMs  throughout  the  Air  Force.  Aircraft-specific  software  is  continu¬ 
ally  updated  by  individual  aircraft  PMs  as  new  applications  (such  as  new  weapons  or  elec¬ 
tronic  countermeasures)  and  upgrades  to  existing  programs  are  developed.  Unlike  the  Navy’s 
CANES,  the  MPS  has  no  predetermined  schedule  for  software  integration.  Rather,  as  aircraft 
PMs  develop  new  software,  they  work  with  the  MPS  program  office  to  ensure  that  integration 
will  be  successful.  The  MPS  PM  has  a  major  challenge  in  ensuring  compatibility  of  new  and 
upgraded  applications.  From  the  beginning  of  the  MPS  project,  there  has  been  an  evolving 
relationship  between  the  PM  (the  government)  and  its  contractors  and  vendors. 
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MPS  Contract  Strategy 

Given  the  magnitude  of  the  software  development  and  integration  challenge,  the  MPS  PM  has 
developed  a  multifaceted  contract  strategy. 

Starting  in  late  2004,  five  multiple  award  IDIQ  software  development  contracts  were 
given  to  five  different  vendors.  The  five  vendors  compete  for  delivery  orders  to  develop  and 
maintain  MPS  software.  Their  tasks  include  (1)  software  development,  (2)  vertical  product 
integration  within  the  MPS  three-tier  architecture,  (3)  technology  insertion,  and  (4)  enterprise 
participation.  The  five  vendors  currently  under  contract  for  these  functions  are  geographically 
dispersed  and  have  five-year  contracts  with  award-fee  incentives.  The  program  also  features  an 
overall  SEIC.  Due  to  the  magnitude  of  the  MPS  integration  task,  the  PM  determined  that  a 
separate,  long-term,  integration  contractor  was  required.  It  awarded  a  12-year  cost-plus  con¬ 
tract  to  SAIC  in  April  2005.  The  SEIC’s  responsibilities  include  systems  engineering  and  inte¬ 
gration  of  components  into  the  MPS  architecture. 


Lessons  from  the  MPS  Experience 

MPS  requires  periodic  integration  of  software  provided  by  most  aircraft  program  offices.  The 
CANES  program  office  will  have  a  similar  requirement  as  PMW  160  receives  applications 
from  other  stakeholders  within  PEO  C4I. 

•  Air  Force  managers  from  the  MPS  program  office  provided  several  helpful  insights  on 
their  program  and  its  contracting  issues.  Among  their  key  insights:  The  requirement  to 
integrate  into  the  MPS  architecture  all  the  applications  provided  by  the  various  aircraft 
program  offices  was  much  more  difficult  than  originally  anticipated.  When  the  Air  Force 
representatives  whom  we  interviewed  heard  more  about  the  CANES  program,  they  pre¬ 
dicted  that  integration  problems  would  occur.  Because  of  the  likelihood  they  perceived 
for  software  problems,  Air  Force  representatives  we  interviewed  recommended  early  and 
frequent  testing  of  software  as  one  means  to  minimize  overall  integration  problems. 

•  Stabilizing  the  MPS  framework  software  (used  by  all  aircraft)  took  longer  than  expected. 
While  the  framework  had  been  stabilized  by  2010,  this  was  a  very  difficult  task.  The  Air 
Force  had  to  change  the  initial  framework  contractor  due  to  inadequate  performance. 

•  As  the  magnitude  of  the  integration  task  grew,  the  government  (i.e.,  the  PM  office)  had  to 
become  more  involved.  Finding  the  right  integration  contractor  was  “a  struggle.” 

•  The  Air  Force  discovered  that,  initially,  none  of  the  five  software  development  contrac¬ 
tors  had  a  sufficient  number  of  experienced  engineers  working  on  the  project.  Many  of 
the  junior  and  middle-grade  software  engineers  lacked  experience  with  Air  Force  aircraft 
operations.  This  lack  of  experience  complicated  project  work.  Getting  the  contractors  to 
find  and  use  software  engineers  with  “domain  experience”  (i.e.,  USAF  flight  operations) 
was  very  important  and  had  to  be  worked  out  over  time. 

•  All  the  software  used  in  MPS  is  GFI  or  GFE.  This  is  because  the  various  aircraft  program 
offices  send  their  applications  to  the  MPS  PM’s  office,  which  then  has  to  integrate  the 
software  with  the  overall  MPS  system. 

•  Having  a  single  prime  contractor  might  have  helped  resolve  problems  in  the  first  years  of 
the  project,  but  IDIQ  guidelines  for  IDIQ  restrict  the  use  of  a  single  prime. 
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•  Government  personnel  from  the  MPS  program  office  are  responsible  for  official  interac¬ 
tion  with  other  PMs,  including  chairing  periodic  meetings  where  software  update  and 
integration  issues  are  discussed.  Contractors  working  for  the  MPS  office  frequently  inter¬ 
act  with  software  developers  in  the  aircraft  program  offices  in  order  to  clarify  software- 
related  issues. 

•  The  current  system  of  five  software  development  (IDIQ)  contractors  and  one  overall  long¬ 
term  integration  contractor  (cost  plus)  seems  to  be  working  well. 


MPS  Lessons  of  Possible  Use  by  CANES 

The  Air  Force’s  MPS  program  has  existed  for  nearly  a  decade.  It  has  many  similarities  to  the 
Navy’s  still-evolving  CANES  program,  most  importantly  the  need  to  integrate  a  wide  variety 
of  software  provided  by  other  offices  into  a  single,  workable  system.  Today,  MPS  is  a  successful 
program  that  provides  an  important  product  to  the  entire  Air  Force. 

In  its  first  years,  MPS  experienced  many  challenges,  most  importantly  in  integrating 
aircraft-specific  software  received  from  fighter,  bomber,  and  other  aircraft  program  offices.  Key 
lessons  for  CANES  appear  to  be  the  following: 

•  Do  not  underestimate  the  magnitude  of  the  integration  challenge. 

•  Work  closely  with  contractors  to  ensure  that  they  have  the  right  expertise  for  the  project. 

•  Appropriately  balance  responsibilities  between  the  government  and  the  contractor(s). 

•  Be  prepared  for  integration  challenges  and  problems  when  CANES  is  first  fielded  to  the 
fleet. 

•  Have  contracts  that  allow  maximum  flexibility,  as  software  problems  are  encountered,  to 
change  the  specific  tasks  that  contractors  perform. 
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Case  Study:  Integrated  Communications  and  Advanced  Network 


The  ICAN  program  was  an  effort  to  integrate  many  networks  needed  on  aircraft  carriers  into 
one.  It  was  installed  on  CVN  68,  69,  76,  and  77.  The  need  to  consolidate  data,  voice,  and  video 
infrastructure  into  a  single  common-network1  architecture,  long  sought  by  the  Navy,2  moti¬ 
vated  the  ICAN  effort. 

ICAN  did  not  meet  its  original  performance  expectations.  Ultimately,  it  was  separated 
into  smaller,  separate  network  programs. 


Initial  Goals 

ICAN  was  developed  by  Northrop  Grumman/Newport  News  (NGNN)  (Obert,  1999). 
Matteo  et  al.  (2004)  described  it  as  both  a  concept  and  as  a  strategy  to  acquire  nondevelop- 
mental  items  and  COTS  technology  to  integrate  voice  and  data  systems  in  the  Nimitz  class. 

The  original  goals  of  ICAN  were  to  (1)  replace  antiquated  shipboard  equipment  with 
COTS  technology,  (2)  integrate  selected  shipboard  communication  systems3  over  an  “advanced 
core  network,”  and  (3)  ideally,  reduce  life-cycle  costs.  Specifically,  ICAN  was  to  support  voice, 
ship  control  (i.e.,  flat-panel  displays),  and  navigation,  as  well  as  machinery  control  systems.4 


1  The  concept  of  “one  network”  for  each  ship  or  even  “one  network”  for  the  surface  fleet  is,  generally  speaking,  ideal  in 
many  respects.  The  National  Research  Council  (2006,  pp.  63-64)  notes: 

The  U.S.  Navy  has  historically  had  distinct  development  communities  for  ship  combat  systems,  tactical  air  combat  sys¬ 
tems,  and  C4ISR.  .  .  .  The  genesis  of  the  division  .  .  .  dates  back  to  days  when  ship  combat  systems  were  devoted  to  the 
completion  of  the  fire-control  loop,  aircraft  fought  aircraft,  and  C4ISR  systems  were  associated  with  the  non-automated 
analysis  of  intelligence.  .  .  .  [Ajdvances  in  computing  and  communications  technology  .  .  .  have  erased  many  of  the  reasons 
for  which  U.S.  Navy  combat  systems  and  C4ISR  systems  were  kept  separate  and  distinct. 

2  Stated  NAVSEA  goals  for  interior  communications  are  (1)  “[Reduction  of  the  quantity  and  types  of  stand[-]alone  voice 
and  video  systems  and  components  through  development  of  system  interface  and  the  introduction  of  new  technology, 
including  LAN  technology”  and  (2)  “[continuing]  the  effort  to  provide  a  single  scalable  voice  communications  system  that 
supports  all  shipboard  mission  requirements”  (see  Bryant,  2008,  slide  6). 

3  Initiatives  to  consolidate  networks  have  persisted  for  some  time:  “A  U.S.  Navy  initiative  that  seeks  to  standardize  ship¬ 
board  data  networking  may  lead  eventually  to  replacement  of  many  of  the  dissimilar,  stand-alone  networks  aboard  Navy 
ships.  At  least  that  is  what  senior  Navy  engineering  leaders  are  hoping.  Navy  engineering  experts  are  keeping  a  close  eye  on 
the  Navy  Integrated  Information  Networking  (NUN)  initiative,  a  joint-command  integrated  product  team”  (Walsh,  2000). 

4  Machinery  control  includes  damage  control,  alarms,  ventilation  control,  and  the  J P-5  fuel  system. 
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ICAN’s  four  components  initially  included  the  following: 

•  an  integrated  voice  system  to  consolidate  telephones,  radios,  shipboard  announcing  sys¬ 
tems,  sound-powered  phones,  and  intercoms 

•  a  machinery  control  system,  integrating  the  aqueous  film-forming  foam  control  and 
monitoring  system,  the  JP-5  fuel  control  and  monitoring  system,  list-control  indication 
system,  and  various  alarm  systems 

•  the  ship  control  indication  system,  centralizing  the  monitoring  of  ship  control  and  navi¬ 
gation  functions 

•  the  navigation-critical  network,  which  distributes  data  to  users  needing  time-critical  nav¬ 
igation  information. 

ICAN  was  designed  to 

1.  replace  multiple  stand-alone  networks  for  voice,  data,  navigation,  and  mechanical  con¬ 
trol  traffic 

2.  be  a  first  step  toward  an  all-electronic  platform 

3.  remain  within  program  cost  and  schedule  constraints 

4.  meet  or  exceed  current  system  functionality,  survivability,  and  availability 

5.  use  an  open  architecture  that  is  transparent  to  vendor  selection,  expandable,  and 
upgradeable 

6.  provide  a  physical  infrastructure  for  emerging  technology  and  future  expansion 

7.  employ  total  ship  engineering 

8.  address  all  logistical  concerns 

9.  validate  and  test  the  integration  of  systems. 

Some  original  program  intentions  follow. 

•  Shipboard  maintenance  and  repair  personnel  were  always  to  have  libraries  of  digital  infor¬ 
mation  readily  available  for  addressing  any  shipboard  problems. 

•  Replacement  parts  were  to  be  easy  to  retrieve  because  the  parts  would  be  from  the  com¬ 
mercial  sector. 

•  Ship  personnel  trained  on  the  ICAN  system  were  to  have  marketable  skills  upon  exit 
from  the  service. 

•  Validation  would  be  established. 

Installation 

NGNN  initially  developed  ICAN  for  the  Reagan  (CVN-76)  and  later  for  the  Eisenhower 
(CVN-69),  but  it  first  installed  a  reduced  system  for  the  Nimitz  (CVN-68).  Problems  were 
first  discovered  with  functionality  and  reliability  after  delivery  on  CVN-68  in  June  2001.  By 
the  time  ICAN  was  to  be  installed  on  the  Vinson  (CVN-70),  the  program  office  for  Aircraft 
Carriers  (PMS  312)  decided  to  replace  ICAN  with  a  government  approach  that  used  three 
separate  federated  systems  for  voice,  navigation,  and  machinery  control  (Matteo  et  ah,  2004). 
Other  carriers  that  had  ICAN  installed  went  to  a  common  functional  baseline  through  a  series 
of  upgrades  (ICAN  Technical  Assessment,  NAVSEA). 
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Reported  Performance 

NAVSEA  documented  several  high-risk  ICAN  problems,  including  problems  that  would 
“adversely  impact  the  ship’s  ability  to  achieve  operational  readiness  or  significantly  impact  life- 
cycle  supportability”  (ICAN  Technical  Assessment).  High-risk  problems  included 

•  erratic  voice  system  operation  and  possible  loss  of  tactical  circuits  directly  affecting  the 
ability  of  the  ship  to  complete  its  mission 

•  ore  network  and  fiber-optic  cable  plant  design  that  was 

-  overly  complex  and  difficult  to  repair 

-  had  obsolete  switches  no  longer  supported  by  the  manufacturer 

-  in  noncompliance  with  DoD  security  requirements 

•  a  lack  of  overall  configuration  management  in  NGNN  system  design.  Platforms  are  deliv¬ 
ered  with  no  configuration  accounting  and  little  or  no  source  code  for  software  life-cycle 
management.  Source  code  is  very  expensive  and  proprietary  and  sometimes  impossible  to 
get,  with  commercial  providers  refusing  to  share  it 

•  no  formal  system  training 

•  ship  staffing  that  did  not  support  system  maintenance 

•  a  COTS  life-cycle  that  was  very  short  in  comparison  to  that  of  GFE  systems 

•  a  lack  of  warranted  technical  authorities,  making  technical  issues  harder  to  resolve. 

Other  Supportability  Problems 

ICAN  had  many  supportability  problems,  including 

•  inaccurate  technical  manuals 

•  obsolete  COTS  parts 

•  software  and  hardware  variation  by  ship 

•  delivered  software  that  was  not  identical  to  the  software  originally  loaded 

•  a  voice  system  comprising  obsolete  and  unique  proprietary  equipment. 

These  problems  ranged  in  importance  for  technical  assessment  and  life-cycle  support 
costs  for  the  ICAN. 

Details  on  Performance  Problems 

ICAN  was  initially  installed  with  Asynchronous  Transfer  Mode  (ATM)  technology  that  did 
not  perform  as  desired.  These  problems  adversely  affected  operational  readiness  on  the  Nimitz ; 
ICAN,  in  the  view  of  a  combat-systems  officer,  failed  “to  adequately  support  mission  require¬ 
ments”  and  representing  “a  significant  step  backward  from  legacy  standards”  (Jackson,  2001). 
The  problems,  which  were  eventually  documented  and  addressed,  related  to  voice  system  issues 
in  particular  and  reliability  issues  in  general  (Schwartz,  2002).5 

One  specific  problem  was  that  voice  and  control  data  shared  the  same  backbone.  Bryant 
and  Wolfe  (2008)  described  the  problem  as  the  “unsuccessful  integration  of  voice  and  data.” 
This  may  have  been  because  quality  of  service  (QoS)  did  not  meet  expectations.  As  a  result  of 


Voice  and  data  networks  were  resegregated  on  some  carriers.  The  problem,  Schwartz  (2002)  noted,  was  that  “[t]ime 
slips  in  the  voice  data  between  the  telephone  system  and  the  Red  Switch  caused  instability.”  Regarding  the  data  network, 
Schwartz  said,  “Timing  slips  across  the  fiber  network  corrupted  these  data  signals.  Data  flooding  during  sea  trials  was 
caused  by  a  failed  crypto  unit,  which  was  replaced.” 
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this  problem,  the  commanding  officer  of  the  Reagan  could  not  launch  aircraft.  Because  NGNN 
had  created  the  design,  the  Navy  did  not  have  the  required  expertise  to  fix  the  problems. 

The  Reagan  had  to  undergo  many  days  of  removal  and  replacement  of  systems  installed 
by  NGNN.  Some  systems  were  removed  because  they  were  poorly  documented  and  the  design 
was  poorly  understood. 

A  key  lesson  learned  from  the  experience  is  “keep  it  simple”  and  segregate  voice  and  data 
on  separate  systems.  Perhaps  complex  network  technology  always  requires  a  shake-out  period. 
The  Navy  did  later  claim  some  improvements  after  the  initial  difficulties. 

The  Eisenhower  received  the  same  capabilities,  and  an  expanded  version  of  ICAN  was 
included  on  the  Reagan.  Our  interviews  suggest  similarly  poor  outcomes,  as  the  PMAG  cor¬ 
roborated  (Matteo  et  ah,  2004). 

Criticism  of  ICAN  tends  to  be  harsh.  Some  interviewees  describe  the  ICAN  implementa¬ 
tion  as  a  disastrous  attempt  to  “throw  a  lot  of  cool  technology”  onto  the  CVN-76  design.  Crit¬ 
ics  say  that  the  Navy  pursued  “science  fair”  projects  without  exercising  oversight. 

There  were  also  more  complex  reasons  for  the  difficulties.  The  program  had  incremen¬ 
tal  funding  and  no  validated  plan  to  consider  available  network  technology  and  how  best  to 
integrate  it.  There  were  a  greater  focus  and  more  personnel  on  mechanical-design  issues  at  the 
expense  of  systems  or  networking  technology  issues  and  personnel.  As  a  result,  there  was  a 
complete  lack  of  system  engineering  by  NGNN  and  no  good  systems  engineering  practices  in 
place.  There  was  not  good  oversight.  There  was  poor  documentation,  with  the  design  docu¬ 
mented  only  in  drawing  notes,  and  no  system  and  subsystem  design  documentation.  In  short, 
ICAN  failed  because  there  were  too  many  components  to  integrate  and  not  all  parties  under¬ 
stood  the  technology. 

Other  specific  issues  with  ICAN  as  detailed  from  Navy  reports  (the  first  four  are  from 
NAVSEA,  the  remaining  are  from  Matteo  et  ah,  2004)  included  the  following: 

•  Installation  of  various  portions  of  ICAN  did  not  support  operational  requirements. 

•  System  security  and  certification  requirements  were  not  followed. 

•  Test  and  training  facilities  did  not  accommodate  the  variety  of  CFE  configurations. 

•  Proprietary  software  required  higher-than-anticipated  life-cycle  support  and  costs  to  the 
government. 

•  Total  ownership  costs  were  not  well  understood.  Neither  dedicated  personnel  nor  Navy 
project  engineers  with  technical  and  program  authority  used  independent  analyses  for 
CFE  and  CFE. 

•  There  was  a  lack  of  technical  authority  within  NAVSEA  for  shipboard  internal  commu¬ 
nications  (IC). 

•  Technical  management  oversight  was  diffuse  and  ineffective. 

•  ICAN  lacked  a  viable  life-cycle  management  plan  and  configuration  control. 

•  ICAN  was  “oversold.” 

•  There  was  no  independent  cost  estimate  for  expenditures. 

•  There  was  no  evidence  that  the  Aircraft  Carrier  Change  Control  Board  had  thoroughly 
reviewed  ICAN  before  approving  it. 

•  The  risk-management  plan  lagged  behind  actual  events  during  the  accelerated  concurrent 
development  and  installation  for  the  first  ICAN  installation. 

•  There  was  no  systemwide  land-based  testing  of  the  system  prior  to  shipboard  installation. 

•  There  was  minimal  government  oversight. 
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•  No  single  designated  individual  was  responsible  for  ICAN  engineering  and  integration. 

•  There  was  a  lack  of  an  adequate  integrated  requirements  package. 

•  There  was  no  software  baseline  and  little  expertise  in  software  testing  at  NGNN. 

•  ICAN  COTS  strategy  was  ill-defined. 

•  There  were  inadequate  test  and  training  facilities  for  shipboard  personnel. 

Design  and  Management  Critique 

The  Navy  managed  the  ICAN  and  its  design  differently  from  past  network  systems.  There  was 
no  independent  analysis  regardless  of  whether  new  equipment  would  be  GFE  or  CFE  (Matteo 
et  ah,  2004).  Instead,  ICAN  used  integrated  product  teams  whose  role  was  program  imple¬ 
mentation,  with  NGNN  serving  as  the  systems  integrator. 

Difficulties  in  Designing  for  Multiple  Stakeholders 

Any  substantial  problem  must  deal  with  many  different  stakeholders,  including,  in  the  Navy, 
those  concerned  with  combat  systems;  hull,  mechanical,  and  electrical  functions;  navigation 
and  control;  and  C4I.  Each  will  have  unique  requirements  and  different  interests  as  well  as  its 
own  charter  and  warrants  to  execute  within  its  area  of  responsibility.  It  is  a  significant  chal¬ 
lenge  to  get  all  to  agree  on  system  requirements.  It  can  also  be  a  challenge  to  write  high-level 
requirements  specifications  that  accommodate  these  stakeholders’  detailed  needs. 

For  ICAN,  each  stakeholder  on  an  IPT  had  an  agenda.  Consequently,  the  ICAN  man¬ 
agement  team  established  an  IPT  coordination-and-management  staff  to  control  team  prob¬ 
lems  and  help  resolve  conflict  when  necessary.  Commercial  subcontractors  generally  believed 
the  proprietary  agreements  with  the  integrator  were  safer  than  those  with  the  government, 
thereby  preferring  to  work  with  a  prime. 

Security  Clearance  Issues 

Security  was  also  a  key  challenge.  There  are  a  high  number  of  communication  security  devices 
on  board  in  distant  locations  that  require  Top  Secret  clearances  to  access  if  the  equipment 
needs  to  be  destroyed.  Also,  shipboard  personnel  have  little  training  for  encryptor  upgrades 
and  (Schank  et  ah,  2006). 

Suggestions  for  Future  Major  Systemwide  Installations 

Suggestions  for  future  major  systemwide  installations  such  as  ICAN,  derived  from  interviews, 
include  the  following  (the  first  six  from  PMAG;  the  remainder  from  NAVSEA):6 

•  Create  an  integrated  requirements  document  that  contains  individual  functional  area 
requirements.  This  allows  network  performance  problems  and  system  deficiencies  to  be 
corrected  from  an  overall  and  subsystem  point  of  view. 

•  Write  a  well-defined  CONOPS  document  that  encompasses  the  entire  system  and  user 
functional  interaction  with  individual  networks,  ship  systems,  and  other  interfaces.  This 
minimizes  operational  and  interface  problems. 


6  This  program  was  conducted  at  a  time  when  acquisition  policy  reflected  a  confidence  in  industry  to  perform  better  than 
government,  resulting  in  minimum  requirements,  rapid  negotiation,  and  government  insight,  not  oversight. 
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•  Implement  a  complete  land-based  test  of  the  system  prior  to  shipboard  installation.  If  that 
is  too  costly,  implement  a  virtual  or  distributed  integration  concept  between  all  system 
sites.  This  investment  will  reduce  overall  life-cycle  costs. 

•  Develop  a  life-cycle  software  maintenance  and  control  plan.  This  ensures  that  software 
maturity  can  be  tested  and  that  a  true  systems  engineering  approach  will  be  followed. 

•  Establish  a  dedicated  organization  entity  or  executive  steering  committee  to  serve  as  life- 
cycle  manager  for  major  systems  like  ICAN  in  an  in-house  Navy  organization.  Staffing 
must  include  headquarters,  naval  organizations,  and  the  private  sector,  given  the  number 
and  expertise  of  personnel  required. 

•  Establish  a  distinct  program  and  system  integration  office  responsible  for  management 
of  all  CFE  and  GFE  system  hardware,  software  maintenance  and  control,  system  inte¬ 
gration,  system-level  functional  requirements,  control  for  services  and  resources,  budget 
formulation,  future  technical  changes,  and  plan  execution. 

•  Establish  test  and  training  facilities  to  accommodate  the  variety  of  CFE  configurations. 
(This  may  be  hard  if  every  system  is  “ship-unique.”) 
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Case  Study:  Acoustic  Rapid  COTS  Insertion 


In  the  mid-1990s,  the  submarine  community  sought  to  improve  its  acoustic  advantage  but 
faced  significant  reductions  to  its  budget.  Those  twin  pressures  led  to  the  Acoustic  Rapid 
COTS  Insertion  (ARCI)  program,  which  pursued  a  new  approach  to  gaining  advanced  capa¬ 
bilities  quickly.  The  ARCI  program  adopted  COTS  technology  to  reduce  costs  and  to  take 
advantage  of  commercial-sector  technological  advances  in  computer-processing  power. 

The  program  updated  hardware  biennially  and  software  annually  to  allow  the  Navy  to 
maintain  a  capability  advantage.  Boats  also  get  a  new  “baseline”  every  four  to  six  years. 

The  Navy  undertook  a  new  approach  to  acquisition  to  allow  such  rapid  upgrades.  The  pro¬ 
gram  became  a  model  for  spiral  development,  evolutionary  acquisition,  and,  specifically,  Mod¬ 
ular  Open  System  Architecture  (MOSA).1  Full  capability,  which  was  not  initially  defined,2 
was  developed  incrementally  over  time.  The  first  system  developed  under  the  ARCI  program 
was  the  towed  array  sonar  on  688-class  submarines.  Eventually,  the  program  encompassed  all 
sonar  systems  on  attack  submarines. 

The  hardware  and  software  were  developed  and  upgraded  by  two  different  contractors. 
Initially,  the  Navy  accomplished  this  through  rigorous  management  of  key  interfaces,  use  of 
open  standards,  and  a  modular  design,  all  business  practices  of  MOSA.  Middleware  was  used 
to  isolate  the  hardware  and  operating  system  from  the  applications  (software). 

Developers  and  users  worked  closely  together  to  define  the  next  increment  of  capability 
in  what  was  called  the  Advanced  Processing  Build  (APB)  process.  This  process  was  used  to 
develop,  select,  test,  and  deploy  new  software.  It  had  four  steps:  identification  of  potential  algo¬ 
rithms,  algorithm  testing,  testing  on  the  current  processor  baseline,  and  at-sea  testing. 

Initially,  the  government  managed  this  process  among  various  participants,  including 
program  office  staff,  NUWC,  academics,  small  businesses,  Lockheed  Martin,  and  DSR.  This 
was  in  part  because  the  program  office  wanted  to  maintain  competition  and  implement  solu¬ 
tions  from  a  broader  range  of  sources,  moving  away  from  a  prime  contractor  model.  The 
program  office  eventually  selected  a  prime  system  integrator,  Lockheed  Martin,  which  was 
responsible  for  much  of  the  systems  engineering  and  integration  of  the  hardware  and  software 
but  was  not  responsible  for  the  development  of  all  hardware  and  software  components.  Lock- 


1  For  a  description  of  these  terms  see  Boudreau,  2006,  p.  5-6. 

2  Because  the  desired  end  state  was  not  known,  increments  were  undertaken  to  provide  improvements  available  within  the 
time  and  budget  available  for  them. 
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heed  Martin  did  not  perform  as  a  lead  system  integrator  but  was  given  COTS  equipment  and 
GFI. 

The  first  installation  for  each  boat  required  significant  shipyard  work.  Shipyard  personnel 
had  to  replace  not  only  racks  but  also  cabling  and  wiring  in  order  to  support  the  new  process¬ 
ing  hardware  and  software.  As  a  result,  the  initial  installations  for  each  boat  were  more  expen¬ 
sive  than  follow-on  installations. 

The  ship  alterations  were  managed  by  the  Strategic  and  Attack  Submarines  Program 
Office  (PMS  392)  and  were  scheduled  to  occur  during  major  availabilities.  The  goal  is  to  have 
the  installations  performed  during  a  30-day  pierside  event.  Each  submarine’s  planning  yard 
assessed  the  work  to  be  performed  and  provided  drawings  to  the  applicable  shipyard  for  the 
work.  Participants  in  this  process  included  Norfolk  Naval  Shipyard,  Portsmouth,  Puget,  Pearl 
Harbor,  Newport  News,  and  Electric  Boat.  In  addition  to  utilizing  the  shipyards,  the  Navy 
used  the  Mid-Atlantic  Regional  Maintenance  Center  (MARMC),  NUWC,  AITs,  and  even 
Tiger  Teams3  to  assist  with  the  installations. 

Now  that  the  program  has  had  several  technical  installations,  less  shipyard  work  is  neces¬ 
sary.  For  software  upgrades,  the  type  commander  schedules  the  work  for  the  MARMC,  which 
will  identify  the  appropriate  installation  to  perform  it,  preferably  at  a  time  other  than  pierside 
availabilities  in  which  more  substantial  work  is  performed.  The  prime  system  integrator  has  a 
minor  role  in  the  installation  process.  Lockheed  Martin  assists  with  loading  the  software,  if 
needed,  and  provides  logistics  support,  such  as  delivery  of  technical  manuals,  parts  lists,  and 
other  interactive  electronic  technical  manuals  (IETMs),  but  its  work  in  this  function  does  not 
appear  to  have  increased  as  the  program  has  matured. 

Later  in  the  program,  working  through  the  Joint  Capability  Integration  Development 
System  (JCIDS)  process  and  achieving  an  appropriate  funding  allocation  from  the  right 
appropriation  accounts  were  notable  challenges.  Initially,  every  required  document  had  to  be 
produced  for  each  increment  of  capability.  Currently,  a  Capability  Development  Document 
(CDD)  and  a  Capability  Production  Document  (CPD)  cover  a  single  technology  of  one  hard¬ 
ware  and  two  software  upgrades.  This  requires  level  amounts  of  Procurement,  research  and 
development  (R&D),  Operation  and  Maintenance,  Navy  funding,  and  SCN  funding  for  the 
systems  going  on  board  in  new  construction. 

Today,  the  ARCI  program  manages  23  configurations  across  71  submarines  (Boudreau, 
2006).  The  program  experienced  a  sevenfold  increase  in  processing  capability  within  its  first  18 
months,  and  life-cycle  costs  have  improved  nearly  fivefold.  As  a  result,  the  program  has  been 
touted  as  a  successful  model  for  getting  improved  capability  to  the  warfighter  quickly  and  at 
a  reduced  cost. 


Contract  Strategy 

Prior  to  ARCI,  submarine  sonar  systems  were  provided  by  a  prime  contractor,  Lockheed 
Martin.  As  noted,  when  the  Navy  decided  to  adopt  a  COTS-based  system  and  more  flexibility 
to  upgrade  technology  quickly,  it  no  longer  desired  a  prime  contractor  acquisition  model.4  The 


3  Tiger  Teams  are  groups  of  individuals  with  specialized  skills  that  are  funded  to  perform  a  specific  task. 

4  Modular  Open  Systems  Architecture  (MOSA)  was  the  approach,  even  though  MOSA  had  not  yet  been  identified. 
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program  manager  sought  a  competitive-teaming  approach  including,  as  noted  earlier,  partici¬ 
pation  of  academics,  small  businesses,  and  government  labs. 

Figure  C.l  shows  the  unique  development  model  used  in  the  ARCI  program. 

Lockheed  Martin  Maritime  Systems  and  Sensors  was  the  initial  Prime  System  Integra¬ 
tor  for  the  tactical  software  development,  a  role  it  retains  today.  NAVSEA’s  Advanced  Sys¬ 
tems  Technology  Office  (ASTO5)  and  the  Submarine  Combat  System  Program  Office  (PMS 
425)  spearheaded  an  APB  for  new  signal  processing  algorithms  to  be  used  in  combat  system 
upgrades. 

Lockheed  Martin  was  also  responsible  for  in-service  support.  A  Small  Business  Innova¬ 
tive  Research  (SBIR)  grant  that  was  originally  sponsored  by  the  attack  submarine  (SSN)  pro¬ 
gram  office  was  used  to  buy  COTS  software  for  signal  processing.  The  Navy  used  the  competi¬ 
tive  format  of  the  SBIR  program  to  select  a  company  for  developing  a  processing  system  using 
COTS  hardware.  A  five-year  contract  was  initially  awarded  to  DSR,  a  small  business  selected 
for  this  program  through  the  SBIR  process,  which  had  developed  a  Multipurpose  Processor. 
The  actual  hardware  was  obtained  from  multiple  vendors  and,  by  2006,  had  been  upgraded 


Figure  C.l 
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5  ASTO  currently  resides  within  PEO  IWS  5. 
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five  times.  DSR  also  developed  the  middleware  that  allowed  new  and  legacy  software  to  run  on 
the  new  processor  and  for  software  and  hardware  to  be  developed  independently. 

Lockheed  and  DSR  had  to  work  together  to  ensure  the  software  would  run  on  the  new 
processors.  As  the  prime  system  integrator,  Lockheed  had  to  ensure  that  the  middleware  and 
processor  design  produced  by  DSR  could  be  integrated  with  the  acoustic  signal  processing 
software.  PMS  425  fostered  a  sense  of  shared  responsibility  for  having  all  work  together  on 
integration.  The  program  office  used  award  and  incentive  fees  to  obtain  cooperation,  as  well  as 
contractor  evaluation,  which  included  interacting  with  other  vendors. 

The  government  maintained  a  great  deal  of  responsibility  for  oversight  and  program  suc¬ 
cess.  A  joint  Navy/industry  team  was  charged  with  researching  and  selecting  the  best  path  for 
technology  insertion.  NUWC  provided  the  performance  specifications  required  of  the  sys¬ 
tems.  At  the  beginning  of  the  program,  the  NAVSEA  ASTO  had  responsibility  for  system 
engineering.  Early  in  the  program,  PMS  425,  the  program  office  responsible  for  ARCI,  had  to 
maintain  this  responsibility.  Because  Lockheed  was  competing  to  be  the  prime  system  inte¬ 
grator  and  NUWC  was  competing  to  provide  software,  neither  could  fulfill  this  role  at  first. 
Once  a  prime  system  integrator  was  established,  system-engineering  responsibilities  transferred 
to  the  prime  (Lockheed  Martin). 

Currently,  the  tech  insertion  team  is  the  primary  governing  body  for  technical  direction 
of  the  program.  The  team  is  responsible  for  providing  guidance  and  specifications  to  Lockheed 
about  what  to  buy.  The  tech  insertion  team,  led  by  government  employees,  also  works  with 
Integrated  Warfare  Systems  (IWS)  to  identify  promising  algorithms  in  the  first  step  of  the  APB 
process.  The  tech  team  leverages  the  R&D  efforts  of  IWS. 

The  program  office  structure  has  helped  the  program  succeed  by  involving  government 
personnel  at  all  levels  of  decisionmaking.  A  complex  arrangement  of  working  groups,  IPTs, 
and  support  and  peer-review  groups  helped  ensure  product  quality.  The  government  oversaw 
all  these  groups  and  teams.  There  was  also  very  strong  leadership  at  multiple  levels,  and  a 
unique  assignment  of  shared  responsibilities  was  adopted  through  a  unique  incentive  structure. 
The  software  developers  (including  NUWC,  academics,  and  persons  from  other  government 
programs)  were  motivated  by  the  potential  for  additional  funding  or  future  work. 

Today,  there  are  four  main  contractors.  Lockheed  Martin  is  responsible  for  building 
hardware,  receiving  hardware  from  other  vendors,  receiving  software  from  other  vendors,  test¬ 
ing,  and  integration.  Until  2010,  the  government  had  a  sole-source  contract  with  Lockheed. 
In  2010,  the  integration  work  was  completed.  Lockheed  is  also  responsible  for  providing  some 
in-service  support  and  managing  spare  parts,  including  those  retrieved  from  removal  of  old 
systems. 

GDAIS  (which  subsequently  bought  DSR)  and  Progeny  each  has  a  contract  for  engineer¬ 
ing  services  and  hardware.  Sedna  has  a  contract  for  software  only. 

All  material  provided  to  Lockheed  is  GFI  or  GFE.  Prior  to  a  production  decision,  there  is 
rigorous  testing  of  the  integrated  system. 

Having  four  main  contractors  and  using  award  and  incentive  fees  has  fostered  competi¬ 
tion  while  providing  incentives  for  cooperation.  If  performance  is  poor,  work  can  be  shifted  to 
other  contractors.  The  program  office  is  currently  assessing  other  strategies,  because  of  current 
policy  changes  affecting  use  of  an  award  fee. 
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Lessons  Learned 

The  ARCI  program  has  had  much  success,  albeit  accompanying  challenges  as  well.  As  the 
program  matured  and  established  relationships,  roles  and  responsibilities  evolved.  Key  insights 
include  the  following: 

•  Initial  equipment  installations  can  require  significant  industrial  activity.  This  work  did 
not  decrease  until  about  the  third  or  fourth  update  cycle,  after  all  boats  had  received  at 
least  the  first  installation  of  ARCI.  Significant  work  will  be  required  again  in  the  near 
future  when  the  existing  network  can  no  longer  support  the  required  upgrades.  This  work 
should  not  be  underestimated. 

•  Senior  leadership  and  mid-level  leadership  empowered  the  cultural  changes  required  for 
successful  implementation  and  innovation.  This  helped  the  program  launch  successfully. 
Continued  involvement  by  the  government  in  key  roles,  such  as  requirements  determina¬ 
tion,  program  direction,  and  the  selection  of  solutions,  has  been  important  to  program 
success. 

•  Communication  among  the  user,  developers,  and  contractors  was  critical  to  program  suc¬ 
cess.  This  was  facilitated  by  contractual  mechanisms,  leadership,  and  the  development  of 
new  processes. 

-  User  participation  was  important  for  getting  feedback  to  the  developer  quickly  enough 
for  implementation  of  the  next  upgrade,  as  well  as  for  operational  testing  and  sailor 
acceptance. 

-  Software  applications  were  selected  through  a  peer-review  process.  This  ensured  level 
competition  and  selection  of  the  best  solution. 

-  The  tech  update  IPT  also  considered  a  peer-review  process  for  selecting  hardware. 

•  The  systems  engineering  function  was  difficult  to  assign  at  first.  The  government  initially 
took  on  this  role  before  giving  it  to  the  system  integrator,  Lockheed  Martin. 

•  Managing  intellectual  property  rights  in  an  environment  where  sharing  design  informa¬ 
tion  and  data  was  critical  to  integration  required  contract  language  to  ensure  government 
acquisition  of  rights  to  data  and  intellectual  property. 

•  New  integrated  testing  processes  are  necessary  when  traditional  end-to-end  operational 
testing  is  too  difficult  and  costly  to  implement  for  every  spiral. 

•  Rapid  upgrading  of  ARCI  resulted  in  training  challenges  for  operators  and  developers. 

•  Traditional  JCIDS  processes  and  funding  allocations  did  not  fit  the  program  well. 

ARCI  Lessons  for  the  CANES  Program 

While  there  are  notable  differences  between  the  ARCI  program  and  CANES,  none  larger 
than  the  ACAT  designation,  there  are  also  some  notable  similarities.  Most  important,  both 
programs  seek  competitive  teaming  in  which  different  participants  develop  hardware  and  soft¬ 
ware  and  a  third  party  integrates  them.  Both  programs  use  an  open-architecture  framework 
to  replace  hardware  and  software  at  a  much  faster  rate  than  has  been  accomplished  by  other 
programs.  Some  key  lessons  for  CANES  are  the  following: 

•  Start  small  and  work  toward  full  capability. 

•  Do  not  underestimate  the  amount  of  work  required  for  the  initial  installations.  Leverag¬ 
ing  the  existing  industrial  base  to  perform  this  function  might  be  most  efficient. 
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•  The  government  must  be  involved  as  a  technical  authority  and  technical  decisionmaker 
and  must  provide  adequate  oversight  and  direction  to  contractors  at  all  levels  of  the  pro¬ 
gram.  The  program  office  should  be  structured  to  best  support  success.  This  may  require 
additional  program  staff. 

•  Planning  for  funding  strategy  and  JCIDS  produces  challenges. 

•  Communication  between  user,  contractor,  and  developer  is  key. 

•  Combining  award  and  incentive  fee  strategies  can  help  foster  success  in  competitive- 
teaming  among  four  separate  prime  contractors. 
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Case  Study:  LPD-17  SWAN 


This  appendix  leverages  past  RAND  studies  sponsored  by  PEO  C4I  (including  Schank  et  al., 
2009,  and  Porche  et  al.,  2010)  to  highlight  relevant  lessons  for  CANES. 


Background  on  LPD-17  and  SWAN 

The  LPD-17  (USS  San  Antonio )  was  delivered  in  2005,  eight  years  after  the  contract  award. 
The  LPD-17’s  SWAN  was  one  of  the  first  attempts  to  use  CFE  and  a  single  LAN  (by  com¬ 
munities  that  might  have  traditionally  had  their  own  onboard  subnets).1  Ship  control,  weapon 
systems,  and  C4ISR  are  all  on  SWAN. 


Initial  Goals  for  SWAN 

The  LPD-17  SWAN  was  built  by  Raytheon.2  It  is  a  fiber-optic  shipboard  wide  area  computer 
network.  It  has  classified  and  unclassified  components,  along  with  vital  and  near-vital  applica¬ 
tions,  including  ship  control  weapon  systems  and  C4I.  It  was  developed  to  be  the  backbone  of 
the  LPD-17  network,  which  supports  thousands  of  physical  and  logical  interfaces  (Raytheon, 
2003;  IHS,  2006).  Ideally,  SWAN  allows  the  crew  to  operate  the  ship  from  almost  any  terminal 
on  board,  a  capability  previously  developed  for  commercial  vessels  but  new  to  Navy  amphibi¬ 
ous  ships.  SWAN  had  two  implementations:  an  ATM  design  and  a  later  integrated  processor 
gigabit  ethernet  (GigE)  implementation  to  modify  the  unpopular  ATM  design.  Eventually, 
SWAN  will  be  replaced  CANES. 

Reported  Performance 

Several  reports  on  general  issues  with  the  LPD-17  have  included  criticisms  of  SWAN.  Hansen 
(2007)  writes 

The  highly  touted  nerve  center  of  the  new,  $1.8  billion  amphibious  ship  San  Antonio 
is  fraught  with  computer  hardware  crashes  that  could  cripple  operations.  .  .  .  Inspec¬ 
tors  discovered  hardware  and  software  failures.  The  system  sometimes  crashes,  hin- 


1  For  the  Nimitz  class,  the  common  ICAN  core  network  is  used  by  the  machinery  control  systems,  integrated  voice  sys¬ 
tems,  and  the  navigation  systems. 

2  Raytheon  is  the  ship  systems  integrator  for  the  LPD-17  class  and  is  under  contract  to  Northrop  Grumman  Ship  Systems 
to  develop  the  SWAN. 
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dering  the  crew’s  ability  to  command  and  control  the  ship  and  launch  Marines  on 
air,  land  and  sea  assaults.  Replacement  parts  for  the  computer  network  were  made 
by  a  company  that  has  gone  out  of  business.  Often,  repair  parts  are  costly  and  need 
to  be  custom-made. 

As  noted  by  PEO  C4I,  SWAN  is  an  “LPD-17  Class  unique  network”  with  CFE.  It  is 
pejoratively  called  a  “boutique  network.”  Because  it  was  designed  and  procured  years  before 
installation,  many  of  its  hardware  components  are  obsolete  and  unsupportable.3 


Networking  Performance  Issues 

SWAN’s  major  performance  flaw  was  its  inability  to  guarantee  a  minimum  amount  of  service 
for  a  diverse  array  of  applications.  The  concept  of  QoS  is  supposed  to  allow  for  such  guarantees. 
SWAN  does  have  a  formal  QoS  at  its  core:  There  is  a  core  network  and  edge  networks  that 
connect  to  the  applications.  In  other  words,  the  core  network  is  a  high-speed  backbone,  and 
the  edges  connect  to  the  ship  from  the  core.  However,  there  were  no  QoS  specifications  for  the 
edge  networks,  which  are  not  part  of  the  core. 

Thus,  for  the  edge  networks,  it  was  first-come,  first-served:  There  may  be  no  problems  on 
a  lightly  loaded  network,  but  when  the  mission  requires  high  bandwidth  (such  as  for  video  and 
imaging),  packets  start  to  be  dropped  by  the  system.  A  key  lesson  is  that  QoS  must  extend  to 
the  “edge”  applications. 

In  hindsight,  the  original  specifications  for  the  LPD-17  network,  made  at  the  ship- 
specification  level,  were  made  at  too  high  a  level.  The  industry  partners  were  given  the  task  of 
applying  the  requirements  to  lower  levels,  with  few  checks  by  the  Navy. 


Cabling  Lessons  Learned 

LPD-17  took  a  phased  approach  to  providing  information  about  C4I  equipment  to  the  ship¬ 
builder.  First,  contractors  told  the  shipbuilder  how  much  weight  and  power  was  required  for 
unidentified  equipment,  and  the  shipbuilder  would  install  the  racks  without  knowing  the 
equipment.  Then,  the  contractor  would  provide  all  equipment  and  intraspace  cabling  while 
the  shipbuilder  bolted  down  the  equipment  and  set  up  the  interspace  cabling.  This  approach 
allowed  LPD-17  to  have  more  up-to-date  C4I  equipment,  but  it  created  problems  with  cabling 
(see  Schank  et  ah,  2009,  for  a  fuller  discussion). 


3  SWAN  was  originally  an  ATM  network.  According  to  PEO  C4I,  “SWAN  network  for  LPD-17  is  based  on  ATM  switch 
technology,  IBUS  and  Augmentix  Servers,  Windows  NT  operating  system,  and  HP  OpenView  network  management.  For 
LPD-18-21,  the  SWAN  network  will  be  TAG-1  Servers  with  the  standard  Navy  Common  PC  Operating  System  Environ¬ 
ment  (COMPOSE)  operating  system  and  INMPro  network  management.  For  LPD-22-25,  the  SWAN  network  will  be 
TAG-2  servers  and  GigE  technology”  (Stull,  2007).  Life-cycle  support  for  SWAN  is  provided  by  Naval  Sea  Systems  Com¬ 
mand  (PMS  317)/Naval  Operations  (OPNAV)  N8. 
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Case  Study:  ADMACS  and  TACs  on  Carriers 


Background  on  the  Aviation  Data  and  Management  Control  System 
(ADMACS) 

ADMACS  is  “a  real-time,  redundant,  configuration  managed,  tactical  Local  Area  Network” 
(U.S.  Navy,  2002).  It  provides  air-operations  network  connectivity,  allowing  automated  plan¬ 
ning  and  reporting  for  launch  and  recovery  activities,  increasing  safety  and  sortie  rate  and 
decreasing  operator  workload  (NAVAIR  Lakehurst,  2002). 

The  success  of  ADMACs  is  due  in  part  to  its  being  built  to  strict  requirements  carefully 
gleaned  from  fleet  engineers  responsible  for  air-operations  networking  needs. 

The  ADMACS  design  team  worked  with  the  operational  users  of  the  system  to  create 
Operational  Requirement  Documents  with  realistic  requirements.  In  the  1990s,  SPAWAR 
developed  an  initial  block  of  ADMACS  that  was  unsuccessful  because  the  system  was  designed 
as  a  general  network  rather  than  as  one  accounting  for  the  unique  requirements  of  aviation 
and  flight  operations.  The  developers  of  the  more  successful  follow-on  block  of  ADMACS  fos¬ 
tered  a  good  relationship  with  system  users,  automated  the  system  as  much  as  possible  to  avoid 
human  error,  and  worked  with  systems  engineers  who  knew  the  software.  One  year  before 
delivery  of  the  system,  the  ADMACS  team  had  several  meetings  to  determine  whether  the 
requirements  were  feasible  or  needed  to  be  modified.  To  reduce  human  error  through  automa¬ 
tion,  the  team  reduced  the  amount  of  manually  input  data  by  allowing  data  to  be  passed  from 
system  to  system  whenever  possible.  NAVAIR  personnel  also  noted  thatNAVAIR  follows  the 
systems  engineering  process. 

In  short,  more  recent  ADMACS  development  succeeded  because  the  team  did  a  thor¬ 
ough  job  of  getting  the  real  requirements  documented.  ADMACS  personnel  claim  to  have 
developed  a  good  roadmap:  They  knew  where  they  wanted  to  go,  where  they  were,  and  where 
they  needed  to  be.  They  also  had  a  far-reaching  plan  that  tried  to  integrate  future  systems. 

The  main  components  of  ADMACS  are  four  tactical  advanced  computer  (TAC)  serv¬ 
ers,  four  network  switches  with  ATM  and  Ethernet  interfaces,  and  an  uninterruptible  power 
supply.  Development  of  the  TAC,  one  of  its  key  components,  provides  lessons  on  how  to 
address  struggles  with  networking  and  IT  systems. 
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Tactical  Advanced  Computer  Four  (TAC-4) 

Brandenburg  (2001)  notes  several  relevant  lessons  learned  from  the  TAC-4  contract1  regarding 
COTS  usage  and  supportability.  Davis  (1995)  describes  TAC-4  as  the  “fourth  generation  in  a 
family  of  workstations  designed  to  satisfy  the  tactical  requirements  of  the  systems  commands, 
type  commands,  composite  warfare/battle  group  commanders,  their  subordinate  units  and 
command  centers.” 

As  Davis  highlights,  the  Navy  lacked  a  structure  for  supporting  TAC-4  systems  after  the 
contract  warranty  period.  There  was  no  centralized  TAC-4  program  office  or  coordinating 
activity  for  support.  The  experience  of  the  TAC-4  program  demonstrates  the  necessity  for  a 
long-term,  Navy-wide  support  structure. 

Brandenburg  (2001)  also  noted  several  more  specific  problems  regarding  support. 

1.  Component  and  configuration  tracking  was  poor.  The  complete  range  of  TAC-4  compo¬ 
nents  was  unknown.  The  number  and  types  of  workstations  purchased  by  the  Navy 
were  not  tracked. 

2.  Data  on  failures  and  replacements  were  imprecise.  Part  numbers  and  true  failure  counts 
were  uncertain.  This  was  caused  in  part  by  poor  communication  with  the  supplier. 

3.  A  complete  range  of  parts  was  not  provided for  the  fleet. 

4.  Maintenance  approaches  were  shaped  more  by  the  original  equipment  manufacturer  than 
by  Navy  users.  Users  seemingly  adopted  the  original  equipment  manufacturer’s  “remove/ 
replace”  reparability  schemes.  No  separate  preventive  maintenance  was  developed,  and 
direct  access  to  TAC-4  technical  experts  was  lost. 

5.  Maintenance  supportability  was  not  properly  verified. 

6.  There  was  a  lack  of  available  engineering  and  vending  data  and  information,  precluding 
preventive  maintenance  and  self-sufficiency.  Navy  users  did  not  own  the  data  required  to 
support  the  fielded  system.  As  a  result,  they  had  limited  ability  to  assess  replacement 
alternatives  and  resolve  fleet  and  repair  issues  quickly. 

7.  Across  the  fleet,  Navy  personnel  were  not  trained  properly  and  had  insufficient  knowledge  of 
hardware  and  software.  The  breadth  of  personnel  who  needed  training  was  larger  than 
originally  anticipated. 

8.  There  was  no  technology  transfer  clause.  The  data  rights  did  not  transfer  to  the  govern¬ 
ment  at  the  end  of  the  contract.  This  forced  some  users  to  procure  original  equipment 
manufacturer  drawing  packages. 

9.  The  technical  manuals  provided  were  insufficient,  i.e.,  they  did  not  provide  the  range  and 
depth  of  information  to  enable  proper  preventive  and  corrective  maintenance.  They  also 
were  not  available  from  a  central  source. 

10.  Navy-wide  control  over  configuration  changes  was  lacking,  and  configuration  management 
devolved  to  users. 


1  TAC-4  is  the  fourth  in  a  line  of  Navy  procurements  for  the  acquisition  of  computer  workstations  and  servers.  Previous 
procurements  resulted  in  the  selection  of  the  Hewlett-Packard  (HP)  9020  series  systems  (Desktop  Tactical  Computer-1,  or 
DTC-1),  Sun  Series  4/XXX  systems  (DTC-2),  and  HP  Apollo  9000  series  systems  (TAC-3). 


APPENDIX  F 


Case  Study:  DDG-1000  Total  Ship  Computing  Environment 
Network 


Background 

In  the  1990s,  there  was  a  push  to  let  industry  assume  risk  and  have  commercial  firms  design 
as  much  as  possible  and  provide  turnkey  systems.  A  case  in  point  is  the  DDG-1000  ( Zumwalt - 
class  destroyer),  for  which  the  whole  platform  was  sent  to  industry  (combat  systems,  radar,  and 
others  were  all  industry-developed).  A  turnkey  approach  was  sought  to  mitigate  risk. 


TSCE-I  Award 

In  2005,  the  Navy  awarded  the  first  TSCE-I  contract  for  the  DDG-1000  to  Raytheon.  It  pro¬ 
vides  standardized  software,  COTS  hardware,  and  supposedly  a  60-percent  reduction  in  ship¬ 
board  personnel  (Raytheon,  2007).  TSCE  is  an  all-ethernet,  all-Internet  protocol  (IP),  Linux- 
based  “solution.”  It  is  complex:  There  are  7  million  lines  of  code  in  the  DDG-1000  software, 
and  this  could  be  a  sustainability  and  supportability  challenge. 

Raytheon  has  taken  parts  of  its  DDG-1000  software  and  used  it  for  other  efforts,  includ¬ 
ing  the  Joint  Land-Attack  Cruise  Missile  Defense  Elevated  Netted  Sensor  System  (JLENS). 
Pieces  of  DDG-1000  software  are  going  into  JFires  as  well.  Several  years  ago,  Raytheon  sub¬ 
mitted  its  TSCE-I  for  potential  use  on  submarines  ( Defense  Daily,  2007). 

According  to  the  developers,  this  software  system  is  designed  to  transition  to  CANES 
over  time,  which  DDG-1000  has  tried  to  accelerate  in  the  past  few  years.  However,  questions 
remain  as  to  whether  the  system  will  be  scalable  and  interoperable  with  CANES. 


Initial  Difficulties 

One  of  the  major  difficulties  in  the  TSCE-I  is  that  IT  knowledge  levels  are  insufficient  to 
manage  both  internal  and  external  communications.  Driving  factors  of  the  lack  of  sufficiency 
are  a  lack  of  formalized  inline  network  encryptor  (INE)  training  in  the  fleet,  the  frequency  of 
crew  transitioning  (one-third  per  year),  and  the  large  number  of  INEs  required  (389)  for  the 
DDG-1000.  Approximately  half  of  INEs  reported  as  malfunctioning  by  the  crew  were  mis- 
configured,  and  contractors  with  the  proper  training  on  INEs  were  involved  only  in  the  INE 
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installation.  Recommendations  for  improving  these  shortcomings  include  providing  more 
training  and  more  shipboard  personnel  with  INE  skills  and  establishing  a  reliable  remote  man¬ 
agement  capability  to  effectively  monitor  the  health  of  all  ship  networks  (Schank  et  ah,  2009). 


APPENDIX  G 


Voice  Networks  on  CVN,  LPD-17,  and  DDG-1000 


This  appendix  leverages  lessons  learned  found  in  NAVSEA  05  briefings  (Bryant,  2008;  Bryant 
and  Wolfe,  2008)  that  focused  on  voice  networks.  These  briefings  covered  lessons  learned  from 
interior  communication  networks  on  CVN-68-class  ICAN  and  the  LPD-17-class  IVCS:1 

•  A  defined  end-user  concept  of  operations  (CONOPS)  is  necessary  to  identify  system 
functional  and  end-user  requirements. 

•  It  is  necessary  to  identify  system  functional  and  end-user  requirements  prior  to  system 
concept  design. 

•  Design  efforts  must  concentrate  on  meeting  documented  system  functional  and  end-user 
requirements  through  appropriate  verification  methods. 

•  Targeting  new  (no  shipboard  exposure)  technologies,  equipment,  or  architecture/ 
configuration  requires  a  risk-analysis  and  management  process  with  full-scale  testing 
under  emulated  (or  actual)  dynamic  shipboard  conditions  (Bryant,  2008). 

Design  elements  that  are  critical  to  system  operational  survivability  must  not  be  com¬ 
promised  without  evidence-of-proof  documentation  that  the  survivability  element  is  no  longer 
applicable.  Table  G.l  highlights  the  technical  risks  found  by  Bryant  (2008)  associated  with 
these  networking  implementations.  Bryant  concluded  that  accurate  CONOPS,  thorough 
functional  requirements,  and  rigorous  testing  are  necessary  for  success. 


IVCS  Documentation  Problems  Found  During  Inspection 

During  inspection  of  the  installed  Wirefree  Portable  Interior  Communication  System  (WPICS) 
for  the  LPD-17’s  IVCS,  it  was  discovered  that  the  ship’s  force  had  not  registered  any  system 
drawings  or  allowance  part  lists.  This  constituted  a  major  risk,  per  the  LPD-17  IVCS’s  Risk 
Assessment  Report,  and  required  a  logistics  plan  and  temporary  repair  parts  supply  support 
to  correct  this  deficiency.  Additionally,  the  ship  did  not  have  the  correct  cable  running  sheets 
or  other  related  drawings  for  the  MarCom  telephone  system.  The  documentation  was  not 
consistent  with  the  “as-built”  configuration  installed  on  the  LPD-17  and,  therefore,  reduced 
the  maintainability  of  the  ship.  Lurthermore,  during  the  inspection  of  the  advanced  announc- 


1  IVCS  was  intended  to  solve  some  of  the  shortcomings  of  older  systems  installed  on  older  ships.  IVCS  combines  the  fea¬ 
tures  of  sound-powered  telephones,  dial  telephones,  and  intercommunications  units  into  one  system.  The  IVCS  can  also 
interface  with  other  shipboard  communications  systems.  The  system  consists  of  terminals  (user  access  devices),  accessories, 
and  two  computer-controlled  Interior  Communications  Switching  Centers. 
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Table  G.1 

Technical  Risks  on  Interior  Communication  Networks 


Top-Level  Acquisition  and  Design  Elements 

TSCE-I 

DDG-1000 

IVCS 

LPD-17 

ICAN 

CVN  68 

No  interior  communication  CONOPS 

X 

X 

X 

No  interior  communication  system  or  end-user  shipboard  functional 
requirements 

X 

X 

X 

No  test  plan  with  fully  integrated  or  dynamic  shipboard  testing 

X 

X 

X 

Immature  technology:  no  prior  MAC-1  shipboard  exposure 

X 

Development  architecture:  no  prior  MAC-1  shipboard  exposure 

X 

X 

X 

Developmental  hardware:  no  prior  MAC-1  shipboard  exposure 

X 

X 

Developmental  software:  no  prior  MAC-1  applications 

X 

X 

X 

Detailed  design  technical  risks  identified 

17 

30 

24 

SOURCE:  Bryant  and  Wolfe,  2008. 


ing  system,  it  was  discovered  that  there  was  no  onboard  maintenance  training  plan.  Since  the 
advanced  announcing  system  was  completely  unique  from  any  other  system,  there  was  also 
no  schoolhouse  training  available.  This  deficiency  increased  the  life-cycle  cost  of  the  advanced 
announcing  system  even  more,  and,  coupled  with  the  fact  that  the  system  was  configured 
improperly,  the  assessment  team  suggested  that  the  entire  system  be  ripped  out  and  replaced. 
The  designated  replacement  chosen  was  the  Central  Amplifier  Announcing  System  (CAAS) 
due  to  its  proven  reliability  and  full  logistic  support. 

Discussion:  Integrated  Versus  Federated  Designs 

One  viewpoint  is  that  a  federation  of  networks  may  actually  be  best  for  the  complex  shipboard 
environment.  A  case  in  point  may  be  voice  networks  discussed  in  this  section.  Many  in  the  car¬ 
rier  community,  based  on  experience  with  the  ICAN  implementation,  argue  that  a  federated 
approach  is  more  pragmatic. 

Sharing  a  single  physical  network  can  place  a  heavy  strain  on  a  ship  network,  especially 
when  one  considers  the  diverse  functions  and  their  demands  on  network  performance  (e.g., 
videoconferencing;  VoIP;  email;  and  the  control  of  the  hull,  mechanical,  and  electrical  func¬ 
tions  and  ship  maneuvering.)  This  is  especially  true  for  IP  and  other  packet-switched  networks, 
which  are  not  designed  for  real-time  control  and  inherently  permit  out-of-order  packet  deliv¬ 
ery.  Although  the  IP  includes  QoS  features,  such  as  integrated  services  and  DiffServ,  an  IP 
network  may  still  be  hard-pressed  to  deliver  hard  real-time  guarantees,  especially  when  it  is  also 
asked  to  carry  large-volume,  multimedia  traffic,  such  as  VoIP  or  videoconferencing,  which  may 
have  its  own  (soft)  real-time  requirements.  This  argues  for  isolating  critical  real-time  functions 
on  their  own  physical  networks,  where  they  can  utilize  whatever  special-purpose  protocols  are 
necessary  to  provide  hard  real-time  guarantees  and  where  they  can  be  uninhibited  by  lower- 
priority  traffic. 

Our  reading  and  interviews  suggest  that  a  middle  ground  between  integration  and  fed¬ 
eration  may  be  the  safest  and  most  flexible  approach. 


APPENDIX  H 


Program  Descriptions 


This  appendix  provides  a  brief  description  of  the  systems  that  will  be  consolidated.  All  of  the 
descriptions  are  direct  quotes  from  the  SPAWAR  website,  unless  noted  otherwise  (PEO  C4I, 
n.d.). 

Automated  Digital  Network  Systems  (ADNS) 

ADNS  is  the  bandwidth  optimization  Program  of  Record  for  the  Navy.  ADNS  provides  the 
only  Quality  and  Class  of  Service  routing  for  multi-service  voice,  video,  and  data  domains 
across  the  available  radio  frequency  paths  that  make  up  the  Ship/Shore  Wide  Area  Network 
(WAN).  This  WAN  is  used  to  support  internal  dissemination  of  information,  as  well  as  exter¬ 
nal  connectivity  to  SIPRNET,  NIPRNET,  and  non-U.S.  Local  Area  Networks.  ADNS  is 
deployed  on  ships,  submarines,  aircraft,  and  at  shore  sites  as  the  Navy’s  entry  point  to  Navy 
tactical/strategic  and  Global  Information  Grid  resources  and  services. 


Integrated  Shipboard  Networks  Systems  (ISNS) 

ISNS  provides  Navy  ships  with  reliable,  high-speed  secret  and  unclassified  Local  Area  Net¬ 
works.  ISNS  provides  the  network  infrastructure,  basic  network  information  distribution  ser¬ 
vices,  and  access  to  the  DISN  Wide  Area  Network  (Secure  and  Nonsecure  Internet  Protocol 
Router  Network-SIPRNET  and  NIPRNET),  which  are  used  by  other  hosted  applications 
or  systems  such  as  NTCSS,  GCCS-M,  DMS,  NSIPS,  NMCP,  NAVMPS,  TBMCS,  and 
TTWCS.  It  enables  real-time  information  exchange  within  the  ship  and  between  afloat  units, 
component  commanders,  shore  sites,  and  fleet  commanders. 


Sensitive  Compartmented  Information  Networks  (SCI) 

The  primary  mission  of  SCI  Networks  includes  providing  special  intelligence  shipboard  ana¬ 
lysts  with  access  to  national  and  service  strategic  and  tactical  databases.  SCI  Networks  is 
the  transport  medium  providing  special  intelligence  data  and  secure  WAN  IP  access  to  ship 
and  shore  national  Web  sites,  and  signals  intelligence  and  intelligence  databases  for  seamless 
interaction  between  shore,  surface,  submarine,  and  airborne  special  intelligence  LANs.  SCI 
Networks  also  provides  network  enterprise  services  critical  to  operational  availability  of  time 
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sensitive  indications  and  warning  data,  GCCS-M  and  DCGS-N  special  intelligence  analytic 
capabilities,  and  implementation  of  advanced  tactical  cryptologic  sensor  functionality. 


Submarine  Local  Area  Network  (SubLAN) 

SubLAN  provides  Navy  submarines  with  reliable  high-speed  secret,  sensitive  but  unclassified 
and  top  secret  Local  Area  Networks.  When  the  SubLAN  network  is  combined  with  other 
subsystems,  it  delivers  an  end-to-end  netcentric  warfare  capability.  AN/USQ-177  Variants 
(V)  1,2, 3, 4  provide  network  infrastructure,  including  an  Unclassified  Wireless  Local  Area 
Network,  servers,  and  the  Common  PC  Operating  System  Environment,  which  provides  the 
server  and  operating  system  environment  for  other  applications  such  as  Non-Tactical  Data 
Processing  System. 


Combined  Enterprise  Regional  Information  Exchange  System-Maritime 
(CENTRIXS-M) 

CENTRIXS-M  utilizes  multiple  security  levels  technology  to  support  simultaneous  access  on  a 
single  thin-client  workstation  to  multiple  networks  representing  several  different  security  levels, 
enclaves,  and  communities  of  interest,  including  SIPRNET,  CENTRIXS  4-EYES,  KOR,  JPN, 
Multi-Coalition  Forces  Iraq  (MCFI),  Combined  Naval  Forces  CENTCOM  (CNFC),  Com¬ 
bined  Maritime  Forces  Pacific  (CMFP),  and  Global  Counter-Terrorism  Force  (GCTF).  The 
capability  will  greatly  improve  timely  access  to  operational  information  on  various  enclaves 
in  a  dynamic  coalition  environment.  This  system  will  also  result  in  significant  reductions  in 
system  administration  and  the  number  of  hardware  devices  at  a  given  workstation. 


Video  Information  Exchange  System  (VIXS) 

VIXS,  the  Video  Exchange  Information  System,  is  used  for  tactical  video  teleconferencing 
(multipoint  secure  video  teleconferencing  [VTC])  between  carriers  and  large-deck  amphibi¬ 
ous  ships.  Shipboard  systems  connect  this  exchange  system  to  the  joint  world-wide  intelligence 
communication  system  (JWICS)  VTC  system  (Friedman,  2006). 


Global  Command  and  Control  System-Maritime  (GCCS-M) 

GCCS-M  provides  maritime  commanders  at  all  echelons  with  a  single,  integrated,  and  scalable 
Command  and  Control  system.  GCCS-M  fuses,  correlates,  filters,  maintains,  and  displays 
location  and  attribute  information  on  friendly,  hostile,  and  neutral  land,  sea,  and  air  forces, 
and  integrates  this  data  with  available  intelligence  and  environmental  information  to  support 
command  decisions. 
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Distributed  Common  Ground  System-Navy  (DCGS-N) 

DCGS-N  provides  the  Navy’s  Intelligence,  Surveillance,  Reconnaissance  and  Targeting  system 
a  standardized  means  of  ingesting,  processing,  exploiting  and  disseminating  all-source  intel¬ 
ligence  data.  DCGS-N  also  initiates  connectivity  to  the  joint  service  and  intelligence  commu¬ 
nity  enterprises. 
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